Messages in this thread | | | Date | Wed, 21 Feb 2007 22:10:31 -0500 | From | Josef Sipek <> | Subject | 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 <jsipek@fsl.cs.sunysb.edu> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |