Re: [Patch] mm tracepoints update - use case.

[Rik van Riel]

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