linux-kernel - Re: [PATCH] Don't touch single threaded PTEs which are on the right node

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] [day] [month] [year] [list]

Message-ID: <20161012154033.GH3078@tassilo.jf.intel.com>
Date:   Wed, 12 Oct 2016 08:40:33 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     Mel Gorman <mgorman@...e.de>
Cc:     Andi Kleen <andi@...stfloor.org>, peterz@...radead.org,
        linux-mm@...ck.org, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Don't touch single threaded PTEs which are on the right
 node

> You shouldn't need to check the number of mm_users and the node the task
> is running on for every PTE being scanned.

Ok.

> 
> A more important corner case is if the VMA is shared with a task running on
> another node. By avoiding the NUMA hinting faults here, the hinting faults
> trapped by the remote process will appear exclusive and allow migration of
> the page. This will happen even if the single-threade task is continually
> using the pages.
> 
> When you said "we had some problems", you didn't describe the workload or
> what the problems were (I'm assuming latency/jitter). Would restricting
> this check to private VMAs be sufficient?

The problem we ran into was that prefetches were not working, but
yes it would also cause extra latencies and jitter and in general
is unnecessary overhead.

It is super easy to reproduce. Just run main() {for(;;);}
It will eventually get some of its pages unmapped.

Yes doing it for private only would be fine. I'll add a check
for that.

-Andi