[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070222020036.GE5867@filer.fsl.cs.sunysb.edu>
Date: Wed, 21 Feb 2007 21:00:39 -0500
From: Josef Sipek <jsipek@....cs.sunysb.edu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Pekka Enberg <penberg@...helsinki.fi>,
Adrian Bunk <bunk@...sta.de>, linux-kernel@...r.kernel.org,
unionfs@...esystems.org
Subject: Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, Feb 21, 2007 at 02:19:44PM -0800, Andrew Morton wrote:
> On Tue, 20 Feb 2007 10:13:56 -0500
> Josef Sipek <jsipek@....cs.sunysb.edu> wrote:
>
> > On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> > > On 2/20/07, Adrian Bunk <bunk@...sta.de> wrote:
> > > > CC fs/unionfs/copyup.o
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In
> > > >function 'create_parents_named':
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620:
> > > >error: 'malloc_sizes' undeclared (first use in this function)
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620:
> > > >error: (Each undeclared identifier is reported only once
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620:
> > > >error: for each function it appears in.)
> > > >make[3]: *** [fs/unionfs/copyup.o] Error 1
> > >
> > > Hmm, why is unionfs playing around with malloc_sizes in the first place?
> > > Jeff?
> >
> > The code is in lookup.c:
> >
> > if (oldsize) {
> > int minsize = malloc_sizes[0].cs_size;
> >
> > if (!newsize || ((oldsize < newsize) && (newsize > minsize))) {
> > kfree(info->lower_paths);
> > info->lower_paths = NULL;
> > }
> > }
> >
> > That's the only user of malloc_sizes. It is supposed to be an optimization -
> > we get the smallest sized piece of memory even if we don't need all of it.
> > This way we don't reallocate & memcpy needlessly.
> >
>
> urgh, no, please don't poke around in slab internals like that.
I agree that it is a hack.
> I can't say more until I've managed to understand your description, which
> might take a while.
It is intended for reallocation of a buffer. The code in lookup.c allocates
some memory, and it may have to reallocate the buffer. The code tries to
prevent some unneeded allocations by looking at what the smallest object the
slabcache gives you is.
I hope this explains it better. There's some discussion about this in the
threads by Pekka Enberg.
Josef "Jeff" Sipek.
--
Linux, n.:
Generous programmers from around the world all join forces to help
you shoot yourself in the foot for free.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists