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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
