[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1469643382.10218.20.camel@surriel.com>
Date: Wed, 27 Jul 2016 14:16:22 -0400
From: Rik van Riel <riel@...riel.com>
To: Michal Hocko <mhocko@...nel.org>,
Janani Ravichandran <janani.rvchndrn@...il.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, hannes@...pxchg.org,
vdavydov@...tuozzo.com, vbabka@...e.cz,
mgorman@...hsingularity.net, kirill.shutemov@...ux.intel.com,
bywxiaobai@....com, rostedt@...dmis.org
Subject: Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath
On Wed, 2016-07-27 at 18:33 +0200, Michal Hocko wrote:
> On Wed 27-07-16 10:47:59, Janani Ravichandran wrote:
> >
> > Add tracepoints to the slowpath code to gather some information.
> > The tracepoints can also be used to find out how much time was
> > spent in
> > the slowpath.
> I do not think this is a right thing to measure.
> __alloc_pages_slowpath
> is more a code organization thing. The fast path might perform an
> expensive operations like zone reclaim (if node_reclaim_mode > 0) so
> these trace point would miss it.
It doesn't look like it does. The fast path either
returns an allocated page to the caller, or calls
into the slow path.
Starting measurement from the slow path cuts out
a lot of noise, since the fast path will never be
slow (and not interesting as a source of memory
allocation latency).
As for the function tracer, I wish I had known
about that!
That looks like it should provide the info that
Janani needs to write her memory allocation latency
tracing script/tool.
As her Outreachy mentor, I should probably apologize
for potentially having sent her down the wrong path
with tracepoints, and I hope it has been an
educational trip at least :)
--
All rights reversed
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists