[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1801171219270.23209@nuc-kabylake>
Date: Wed, 17 Jan 2018 12:23:04 -0600 (CST)
From: Christopher Lameter <cl@...ux.com>
To: Mel Gorman <mgorman@...e.de>
cc: Henry Willard <henry.willard@...cle.com>,
akpm@...ux-foundation.org, kstewart@...uxfoundation.org,
zi.yan@...rutgers.edu, pombredanne@...b.com, aarcange@...hat.com,
gregkh@...uxfoundation.org, aneesh.kumar@...ux.vnet.ibm.com,
kirill.shutemov@...ux.intel.com, jglisse@...hat.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: numa: Do not trap faults on shared data section
pages.
On Tue, 16 Jan 2018, Mel Gorman wrote:
> My main source of discomfort is the fact that this is permanent as two
> processes perfectly isolated but with a suitably shared COW mapping
> will never migrate the data. A potential improvement to get the reported
> bandwidth up in the test program would be to skip the rest of the VMA if
> page_mapcount != 1 in a COW mapping as it would be reasonable to assume
> the remaining pages in the VMA are also affected and the scan is wasteful.
> There are counter-examples to this but I suspect that the full VMA being
> shared is the common case. Whether you do that or not;
Same concern here. Typically CAP_SYS_NICE will bypass the check that the
page is only mapped to a single process and the check looks exactly like
the ones for manual migration. Using CAP_SYS_NICE would be surprising
here since autonuma is not triggered by the currently running process.
Can we configure this somehow via sysfs?
Powered by blists - more mailing lists