[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200417121629.GA3758@techsingularity.net>
Date: Fri, 17 Apr 2020 13:16:29 +0100
From: Mel Gorman <mgorman@...hsingularity.net>
To: SeongJae Park <sjpark@...zon.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"Huang, Ying" <ying.huang@...el.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...riel.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Tejun Heo <tj@...nel.org>, Dave Hansen <dave.hansen@...el.com>,
Tim Chen <tim.c.chen@...el.com>,
Aubrey Li <aubrey.li@...el.com>
Subject: Re: Re: Re: [RFC] autonuma: Support to scan page table asynchronously
On Fri, Apr 17, 2020 at 12:21:29PM +0200, SeongJae Park wrote:
> On Fri, 17 Apr 2020 12:04:17 +0200 Peter Zijlstra <peterz@...radead.org> wrote:
>
> > On Fri, Apr 17, 2020 at 09:05:08AM +0200, SeongJae Park wrote:
> > > I think the main idea of DAMON[1] might be able to applied here. Have you
> > > considered it?
> > >
> > > [1] https://lore.kernel.org/linux-mm/20200406130938.14066-1-sjpark@amazon.com/
> >
> > I've ignored that entire thing after you said the information it
> > provides was already available through the PMU.
>
> Sorry if my answer made you confused. What I wanted to say was that the
> fundamental access checking mechanism that DAMON depends on is PTE Accessed bit
> for now, but it could be modified to use PMU or other features instead.
I would not be inclined to lean towards either approach for NUMA
balancing. Fiddling with the accessed bit can have consequences for page
aging and residency -- fine for debugging a problem, not to fine for
normal usage. I would expect the PMU approach would have high overhead
as well as taking over a PMU counter that userspace debugging may expect
to be available.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists