lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ