Messages in this thread | | | Date | Thu, 18 Jun 2009 15:40:52 -0400 | From | Rik van Riel <> | Subject | Re: [Patch] mm tracepoints update - use case. |
| |
Larry Woodman wrote:
>> - Please don't display mm and/or another kernel raw pointer. >> if we assume non stop system, we can't use kernel-dump. Thus kernel pointer >> logging is not so useful. > > OK, I just dont know how valuable the trace output is with out some raw > data like the mm_struct.
I believe that we do want something like the mm_struct in the trace info, so we can figure out which process was allocating pages, etc...
>> - Please consider how do this feature works on mem-cgroup. >> (IOW, please don't ignore many "if (scanning_global_lru())")
Good point, we want to trace cgroup vs non-cgroup reclaims, too.
>> - tracepoint caller shouldn't have any assumption of displaying representation. >> e.g. >> wrong) trace_mm_pagereclaim_pgout(mapping, page->index<<PAGE_SHIFT, PageAnon(page)); >> good) trace_mm_pagereclaim_pgout(mapping, page) > > OK. > >> that's general and good callback and/or hook manner.
How do we figure those out from the page pointer at the time the tracepoint triggers?
I believe that it would be useful to export that info in the trace point, since we cannot expect the userspace trace tool to figure out these things from the struct page address.
Or did I overlook something here?
-- All rights reversed.
| |