[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170706161302.aupbhvld3yew3cjl@hirez.programming.kicks-ass.net>
Date: Thu, 6 Jul 2017 18:13:02 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Laurent Dufour <ldufour@...ux.vnet.ibm.com>
Cc: paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
kirill@...temov.name, ak@...ux.intel.com, mhocko@...nel.org,
dave@...olabs.net, jack@...e.cz,
Matthew Wilcox <willy@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
haren@...ux.vnet.ibm.com, khandual@...ux.vnet.ibm.com,
npiggin@...il.com, bsingharora@...il.com,
Tim Chen <tim.c.chen@...ux.intel.com>
Subject: Re: [RFC v5 09/11] mm: Try spin lock in speculative path
On Thu, Jul 06, 2017 at 05:29:26PM +0200, Laurent Dufour wrote:
> Based on the benchmarks I run, it doesn't fail so much often, but I was
> thinking about adding some counters here. The system is accounting for
> major page faults and minor ones, respectively current->maj_flt and
> current->min_flt. I was wondering if an additional type like async_flt will
> be welcome or if there is another smarter way to get that metric.
>
> Feel free to advise.
You could stick a tracepoint in, or extend PERF_COUNT_SW_PAGE_FAULTS*.
Powered by blists - more mailing lists