[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1469645861.10218.23.camel@surriel.com>
Date: Wed, 27 Jul 2016 14:57:41 -0400
From: Rik van Riel <riel@...riel.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Janani Ravichandran <janani.rvchndrn@...il.com>,
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 20:44 +0200, Michal Hocko wrote:
> On Wed 27-07-16 14:16:22, Rik van Riel wrote:
> >
> > 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.
> I must be missing something here but what prevents
> __alloc_pages_nodemask->get_page_from_freelist from doing
> zone_reclaim?
You are right!
Guess the script may need to collect all the
tracing output from __alloc_pages_nodemask on
up, and then filter the output so only the
interesting (read: long duration) traces get
dumped out to a file.
--
All rights reversed
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists