Re: [patch][rfc] fs: shrink struct dentry

[Nick Piggin <npiggin@suse.de>]

On Tue, Dec 02, 2008 at 02:49:18PM +0000, John Levon wrote:
> On Tue, Dec 02, 2008 at 02:49:26PM +0100, Nick Piggin wrote:
> 
> > > I can't believe I'm having to argue that you need to test your code. So
> > > I think I'll stop.
> > 
> > Code was tested. It doesn't affect my normal oprofile usage (it's
> > utterly within the noise, in case that wasn't obvious to you).
> 
> Then, heck, why didn't you say so?! I just went and read the whole
> exchange and this is the first time you actually stated you tested the
> impact of your patch on oprofile overhead.

This was just in running some silly benchmark like oprofile+tbench,
but I'm fairly sure it a) probably didn't have many entries in the
cookies cache -- at least not enough to create big hash chains, and
b) wasn't hitting get_dcookie very often, and c) AFAIKS, all paths to
get_dcookie go through fast_get_dcookie so I actually can't see any
possible way that this patch could increase the number of hash lookups
anyway.

Given that, I was 99.9% sure it will be OK. But I like confirmation
from you.

I didn't do any major test where I try to force thousands of entries
into dcookie subsystem or anything, but if you care to give a test
case I can try.

mmap_sem and find_vma is much more annoying in oprofile :) Speaking of
which: is there a mode it can be set in to do kernel only profiling so
it does not bother with userspace samples at all? That would be really
nice for profiling the kernel in the kinds of workloads that hit
mmap_sem and vma cache often because oprofile interferes with that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>