lkml.org 
[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[patch-2.4.0-test6-pre6] fs_cachep (was Re: [PATCH] signal_struct slab cache)
Hi Mark and Linus,

Although Mark's comments are definitely correct (AFAICS) - I remembered
that the classical SLAB paper mentioned one of the advantages of
converting things to using slab allocator in order to serve as some sort
of system administration tool - i.e. to see which subsystems are putting
lots of pressure on VM and which aren't. If they all use generic
kmalloc/kfree this information/stats is not visible.

So I converted p->fs allocation to a SLAB cache of its own - see the patch
attached - tested under 2.4.0-test6-pre6.

A copy of the patch is on:

http://www.moses.uklinux.net/patches/fscache-2.4.0-test6-pre6.patch

Regards,
Tigran

On Mon, 7 Aug 2000, Mark Hemment wrote:

> Tigran,
>
> > What about small (36 byte) things like fs_struct - looks like it is the
> > only one left as kmalloc'd still - is there any point to convert it to a
> > cache of its own - fs_cachep?
> >
> > I understand it will come from 64 byte generic cache so perhaps it is just
> > as wasteful? Or do you (SLAB) store some useful ctl info in those
> > remaining bytes?
>
> Probably not worth it for fs_cachep. But should be need investigated.
>
> My old slab allocator would fit a control struct behind the actual
> object (in between the padding to an L1 bound). With Manfred's changes, I
> believe this to still be the case.
>
> The new allocator I'm working on will also fit the control struct
> between objects (and at the end of a slab, and off-slab). Plus, it will
> allow different caches (with similar attributes) to share slabs - this is
> only useful on low memory machines for caches which tend to have very few
> allocations from them (say, the uid-cache, which takes up a full page for
> only a few allocations on some system usage patterns - it would be
> better off using one of the general sized caches - which is why I
> originally implemented kmem_find_general_cachep()).
>
> Mark
>
>
diff -urN -X dontdiff linux/fs/dcache.c fscache/fs/dcache.c
--- linux/fs/dcache.c Mon Aug 7 08:57:57 2000
+++ fscache/fs/dcache.c Mon Aug 7 15:50:40 2000
@@ -1240,6 +1240,9 @@
/* SLAB cache for buffer_head structures */
kmem_cache_t *bh_cachep;

+/* SLAB cache for fs_struct structures */
+kmem_cache_t *fs_cachep;
+
void __init vfs_caches_init(unsigned long mempages)
{
bh_cachep = kmem_cache_create("buffer_head",
@@ -1253,6 +1256,12 @@
SLAB_HWCACHE_ALIGN, NULL, NULL);
if (!names_cachep)
panic("Cannot create names SLAB cache");
+
+ fs_cachep = kmem_cache_create("fs_cache",
+ sizeof(struct fs_struct), 0,
+ SLAB_HWCACHE_ALIGN, NULL, NULL);
+ if (!fs_cachep)
+ panic("Cannot create fs_struct SLAB cache");

files_cachep = kmem_cache_create("files_cache",
sizeof(struct files_struct), 0,
diff -urN -X dontdiff linux/include/linux/slab.h fscache/include/linux/slab.h
--- linux/include/linux/slab.h Mon Aug 7 08:57:58 2000
+++ fscache/include/linux/slab.h Mon Aug 7 15:50:49 2000
@@ -72,6 +72,7 @@
extern kmem_cache_t *filp_cachep;
extern kmem_cache_t *dquot_cachep;
extern kmem_cache_t *bh_cachep;
+extern kmem_cache_t *fs_cachep;

#ifdef CONFIG_SMP
extern unsigned long slab_cache_drain_mask;
diff -urN -X dontdiff linux/kernel/exit.c fscache/kernel/exit.c
--- linux/kernel/exit.c Mon Aug 7 08:57:58 2000
+++ fscache/kernel/exit.c Mon Aug 7 15:48:26 2000
@@ -229,7 +229,7 @@
dput(fs->altroot);
mntput(fs->altrootmnt);
}
- kfree(fs);
+ kmem_cache_free(fs_cachep, fs);
}
}

diff -urN -X dontdiff linux/kernel/fork.c fscache/kernel/fork.c
--- linux/kernel/fork.c Mon Aug 7 08:57:58 2000
+++ fscache/kernel/fork.c Mon Aug 7 15:49:38 2000
@@ -318,7 +318,7 @@

static inline struct fs_struct *__copy_fs_struct(struct fs_struct *old)
{
- struct fs_struct *fs = kmalloc(sizeof(*old), GFP_KERNEL);
+ struct fs_struct *fs = kmem_cache_alloc(fs_cachep, GFP_KERNEL);
/* We don't need to lock fs - think why ;-) */
if (fs) {
atomic_set(&fs->count, 1);
\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.245 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site