On 2017/11/23 22:36, Mel Gorman wrote: > On Thu, Nov 23, 2017 at 01:25:30PM +0100, Michal Hocko wrote: >> On Thu 23-11-17 11:43:36, peter.enderborg@xxxxxxxx wrote: >>> From: Peter Enderborg <peter.enderborg@xxxxxxxx> >>> >>> The warning of slow allocation has been removed, this is >>> a other way to fetch that information. But you need >>> to enable the trace. The exit function also returns >>> information about the number of retries, how long >>> it was stalled and failure reason if that happened. >> >> I think this is just too excessive. We already have a tracepoint for the >> allocation exit. All we need is an entry to have a base to compare with. >> Another usecase would be to measure allocation latency. Information you >> are adding can be (partially) covered by existing tracepoints. >> > > You can gather that by simply adding a probe to __alloc_pages_slowpath > (like what perf probe does) and matching the trigger with the existing > mm_page_alloc points. This is a bit approximate because you would need > to filter mm_page_alloc hits that do not have a corresponding hit with > __alloc_pages_slowpath but that is easy. > > With that probe, it's trivial to use systemtap to track the latencies between > those points on a per-processes basis and then only do a dump_stack from > systemtap for the ones that are above a particular threshold. This can all > be done without introducing state-tracking code into the page allocator > that is active regardless of whether the tracepoint is in use. It also > has the benefit of working with many older kernels. Please see my attempt at http://lkml.kernel.org/r/1510833448-19918-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx . Printing just current thread is not sufficient for me. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
