On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote: > >Instead, one says "what pages are being used by my application", then, for > > That includes unmapped pagecache being used by my application, doesn't it? > Maybe that's too hard to do via /proc so we forget about it...
It'd be really nice to have a window into the pagecache too. But I for one couldn't come up with a sensible scheme for it. > >each of those pages "what is that page's state". So the first step is to > >collect all the pfns from /proc/$(pidof my-application)/pagemap and then to > >use those pfns to look the individual pages up in /proc/kpagemap. > > OK I realise you could do it that way, but systemtap can definitely be > used as a tool for understanding application behaviour in the context of > the kernel, I think? The purpose for it is so that various little bits > of deep kernel internals do not have to be exposed on a case by case basis. > > If kprobes is simply crappy and doesn't work properly for this, then I > could accept that. I'm not someone trying to get this info. So why can't > it be used? (not just for kpagemap, but for clear_refs and all that gunk > too). kprobes is good for looking at events, but bad for looking at state. Especially metric shitloads of state. > > If you really want to know "who is using page 123435" then you'd need to > > search /proc/*/pagemap. There are possibly legitimate reasons why an > > application developer would want to at least pertially perform such an > > operation ("who am I sharing with"), but I doubt if it's the common case. > > Maybe. How about LRU? Reclaim performance is bad, and you want to work out > which pages keep going off the end of it, or which pages keep getting > written out via it, or who's pages are on the active list, forcing mine > out. Those are actually probably a good match for systemtap as they're all events. -- Mathematics is the supreme nostalgia of our time. - 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/