Re: [-mm patch] UNION_FS must depend on SLAB
On Thu, 22 Feb 2007, Pekka Enberg wrote: > I think we can merge krealloc without unionfs. I'll whoop up a new patch as > per Christoph's suggestions. I think at least XFS already has its own realloc > and there might be some other open-coded users. It's not _changing_ the slab > as much as adding new functionality that makes sense fron a general point of > view. I really like the krealloc idea. Could we useful elsewhere to extend objects and it is similar to the realloc() available in glibc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Thu, Feb 22, 2007 at 08:18:39AM +0200, Pekka Enberg wrote: > Pekka Enberg wrote: > >The ksize exports we can add later if unionfs is to be merged. > > Actually, we probably don't need it after the krealloc optimizations. I > think we need a new unionfs patch too... :) I'm for it! Josef "Jeff" Sipek. -- Don't drink and derive. Alcohol and algebra don't mix. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
Pekka Enberg wrote: The ksize exports we can add later if unionfs is to be merged. Actually, we probably don't need it after the krealloc optimizations. I think we need a new unionfs patch too... :) Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
Hi Andrew, Andrew Morton wrote: Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. I think we can merge krealloc without unionfs. I'll whoop up a new patch as per Christoph's suggestions. I think at least XFS already has its own realloc and there might be some other open-coded users. It's not _changing_ the slab as much as adding new functionality that makes sense fron a general point of view. The ksize exports we can add later if unionfs is to be merged. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote: > On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote: > > > > 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. > > Problem is, it doesn't seem that we'll be merging unionfs any time soon so > we shouldn't be adding slab infrastructure on its behalf. And I'd prefer > not to have to carry slab changes in a filesystem tree. > > Although if the changes are generally ok-looking and are compact then it'd > be OK, but I do need to be alert for someone who comes along and uses that > infrastructure in an unrelated patch, which has happened before. When I > prep the patch for an upstream merge, oops, doesn't compile any more. Sounds reasonable to be weary of patches like that... > So for now, it'd be best to jsut forget about the optimisation. Well... > How useful is it, anyway? The code in lookup gets called frequently enough that I'm not sure. Whenever one touches a file on a read-only branch, a copyup is done. This may have to recreate the directory hierarchy leading up to the file - since the VFS doesn't have such code, unionfs builds up a stack of all the path components, and then it pops them off one at a time calling vfs_mkdir for each. The stack creation is where we do this "reallocation." Josef "Jeff" Sipek. -- I'm somewhere between geek and normal. - Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Unionfs] Re: [-mm patch] UNION_FS must depend on SLAB
For what it's worth, the new branch-management code also needs realloc(): right now I do a kfree/kalloc instead. So I'm all for having a true krealloc function. Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote: > > 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. Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. Although if the changes are generally ok-looking and are compact then it'd be OK, but I do need to be alert for someone who comes along and uses that infrastructure in an unrelated patch, which has happened before. When I prep the patch for an upstream merge, oops, doesn't compile any more. So for now, it'd be best to jsut forget about the optimisation. How useful is it, anyway? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> > > On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Tue, 20 Feb 2007 10:13:56 -0500
Josef Sipek <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> > On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> 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.
If you want to propose an extension to the slab ABI the please do so and
we'll take a look at it.
I can't say more until I've managed to understand your description, which
might take a while.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Tue, 20 Feb 2007 10:13:56 -0500
Josef Sipek [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] 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.
If you want to propose an extension to the slab ABI the please do so and
we'll take a look at it.
I can't say more until I've managed to understand your description, which
might take a while.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek [EMAIL PROTECTED] wrote: 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. Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. Although if the changes are generally ok-looking and are compact then it'd be OK, but I do need to be alert for someone who comes along and uses that infrastructure in an unrelated patch, which has happened before. When I prep the patch for an upstream merge, oops, doesn't compile any more. So for now, it'd be best to jsut forget about the optimisation. How useful is it, anyway? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Unionfs] Re: [-mm patch] UNION_FS must depend on SLAB
For what it's worth, the new branch-management code also needs realloc(): right now I do a kfree/kalloc instead. So I'm all for having a true krealloc function. Erez. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote: On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek [EMAIL PROTECTED] wrote: 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. Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. Although if the changes are generally ok-looking and are compact then it'd be OK, but I do need to be alert for someone who comes along and uses that infrastructure in an unrelated patch, which has happened before. When I prep the patch for an upstream merge, oops, doesn't compile any more. Sounds reasonable to be weary of patches like that... So for now, it'd be best to jsut forget about the optimisation. Well... How useful is it, anyway? The code in lookup gets called frequently enough that I'm not sure. Whenever one touches a file on a read-only branch, a copyup is done. This may have to recreate the directory hierarchy leading up to the file - since the VFS doesn't have such code, unionfs builds up a stack of all the path components, and then it pops them off one at a time calling vfs_mkdir for each. The stack creation is where we do this reallocation. Josef Jeff Sipek. -- I'm somewhere between geek and normal. - Linus Torvalds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
Hi Andrew, Andrew Morton wrote: Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. I think we can merge krealloc without unionfs. I'll whoop up a new patch as per Christoph's suggestions. I think at least XFS already has its own realloc and there might be some other open-coded users. It's not _changing_ the slab as much as adding new functionality that makes sense fron a general point of view. The ksize exports we can add later if unionfs is to be merged. Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
Pekka Enberg wrote: The ksize exports we can add later if unionfs is to be merged. Actually, we probably don't need it after the krealloc optimizations. I think we need a new unionfs patch too... :) Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Thu, Feb 22, 2007 at 08:18:39AM +0200, Pekka Enberg wrote: Pekka Enberg wrote: The ksize exports we can add later if unionfs is to be merged. Actually, we probably don't need it after the krealloc optimizations. I think we need a new unionfs patch too... :) I'm for it! Josef Jeff Sipek. -- Don't drink and derive. Alcohol and algebra don't mix. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Thu, 22 Feb 2007, Pekka Enberg wrote: I think we can merge krealloc without unionfs. I'll whoop up a new patch as per Christoph's suggestions. I think at least XFS already has its own realloc and there might be some other open-coded users. It's not _changing_ the slab as much as adding new functionality that makes sense fron a general point of view. I really like the krealloc idea. Could we useful elsewhere to extend objects and it is similar to the realloc() available in glibc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
For the time being, I included it in unionfs.git. I wouldn't mind having this dependency disappear. Thanks, Josef "Jeff" Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Unionfs] Re: [-mm patch] UNION_FS must depend on SLAB
Josef Sipek:
> 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.
How about exporting ksize to modules, and introduce a new function such
like this?
Of course, adding gfp_t to its parameter list make this function more generic.
void *kzrealloc(void *p, int nused, int new_sz)
{
void *q;
if (new_sz <= nused)
return p;
if (new_sz <= ksize(p)) {
memset(p + nused, 0, new_sz - nused);
return p;
}
q = kmalloc(new_sz, GFP_KERNEL);
if (unlikely(!q))
return NULL;
memcpy(q, p, nused);
memset(q + nused, 0, new_sz - nused);
kfree(p);
return q;
}
Junjiro Okajima
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> 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.
Josef "Jeff" Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] 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.
Josef Jeff Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Unionfs] Re: [-mm patch] UNION_FS must depend on SLAB
Josef Sipek:
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.
How about exporting ksize to modules, and introduce a new function such
like this?
Of course, adding gfp_t to its parameter list make this function more generic.
void *kzrealloc(void *p, int nused, int new_sz)
{
void *q;
if (new_sz = nused)
return p;
if (new_sz = ksize(p)) {
memset(p + nused, 0, new_sz - nused);
return p;
}
q = kmalloc(new_sz, GFP_KERNEL);
if (unlikely(!q))
return NULL;
memcpy(q, p, nused);
memset(q + nused, 0, new_sz - nused);
kfree(p);
return q;
}
Junjiro Okajima
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
For the time being, I included it in unionfs.git. I wouldn't mind having this dependency disappear. Thanks, Josef Jeff Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] UNION_FS must depend on SLAB
On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-mm1: >... > git-unionfs.patch >... > git trees >... <-- snip --> ... 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 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.20-mm2/fs/Kconfig.old 2007-02-19 18:19:19.0 +0100 +++ linux-2.6.20-mm2/fs/Kconfig 2007-02-19 18:20:28.0 +0100 @@ -1052,7 +1052,7 @@ config UNION_FS tristate "Union file system (EXPERIMENTAL)" - depends on EXPERIMENTAL + depends on SLAB && EXPERIMENTAL help Unionfs is a stackable unification file system, which appears to merge the contents of several directories (branches), while keeping - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] UNION_FS must depend on SLAB
On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote: ... Changes since 2.6.20-mm1: ... git-unionfs.patch ... git trees ... -- snip -- ... 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 -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.20-mm2/fs/Kconfig.old 2007-02-19 18:19:19.0 +0100 +++ linux-2.6.20-mm2/fs/Kconfig 2007-02-19 18:20:28.0 +0100 @@ -1052,7 +1052,7 @@ config UNION_FS tristate Union file system (EXPERIMENTAL) - depends on EXPERIMENTAL + depends on SLAB EXPERIMENTAL help Unionfs is a stackable unification file system, which appears to merge the contents of several directories (branches), while keeping - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
