linux-kernel - Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to slowpath

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]

Date:   Wed, 18 Jan 2017 10:03:41 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Ganapatrao Kulkarni <gpkulkarni@...il.com>,
        Michal Hocko <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to
 slowpath

On Tue, Jan 17, 2017 at 11:16:09PM +0100, Vlastimil Babka wrote:
> This is a preparation for the following patch to make review simpler. While
> the primary motivation is a bug fix, this could also save some cycles in the
> fast path.
> 
> Signed-off-by: Vlastimil Babka <vbabka@...e.cz>

To be clear, the fast path savings will be when cpusets are active even
though that is still a good thing.  Most of the time, they are disabled
static branches. I see there were concerns raised that this would retry
the kswapd paths but I don't really see the issue. The same wakeup could
occur due to a cpuset switch with the existing retry. Even a potentially
spurious wakeup of kswapd is ok if the slow paths were being hit anyway
as kswapd is probably still awake from the first wakeup. If anything,
the fact that kswapd wakeups ignore cpusets and potentially wakes kswapd
on forbidden nodes is more problematic but not worth fixing. If kswapd
needs to wake on a node outside the cpuset then it's going to be by some
active process outside the cpuset some time in the future so;

Acked-by: Mel Gorman <mgorman@...hsingularity.net>

-- 
Mel Gorman
SUSE Labs