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/