linux-kernel - Re: [RFC 0/5] disable pcplists during page isolation

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, 9 Sep 2020 12:54:45 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     David Hildenbrand <david@...hat.com>, linux-mm@...ck.org
Cc:     linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...nel.org>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        Oscar Salvador <osalvador@...e.de>,
        Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [RFC 0/5] disable pcplists during page isolation

On 9/8/20 8:29 PM, David Hildenbrand wrote:
> On 07.09.20 18:36, Vlastimil Babka wrote:
>> As per the discussions [1] [2] this is an attempt to implement David's
>> suggestion that page isolation should disable pcplists to avoid races. This is
>> done without extra checks in fast paths, as I mentioned should be possible in
>> the discussion, and explained in patch 5. Patches 1-4 are preparatory cleanups.
>> 
>> Note this is untested RFC for now. Based on v5.9-rc4 plus Pavel's patch [2]
>> (slated as a quick fix for mainline+stable).
>> 
>> [1] https://lore.kernel.org/linux-mm/20200901124615.137200-1-pasha.tatashin@soleen.com/
>> [2] https://lore.kernel.org/linux-mm/20200903140032.380431-1-pasha.tatashin@soleen.com/
>> 
>> Vlastimil Babka (5):
>>   mm, page_alloc: clean up pageset high and batch update
>>   mm, page_alloc: calculate pageset high and batch once per zone
>>   mm, page_alloc(): remove setup_pageset()
>>   mm, page_alloc: cache pageset high and batch in struct zone
>>   mm, page_alloc: disable pcplists during page isolation
>> 
>>  include/linux/gfp.h    |   1 +
>>  include/linux/mmzone.h |   2 +
>>  mm/internal.h          |   4 ++
>>  mm/memory_hotplug.c    |  24 +++----
>>  mm/page_alloc.c        | 138 ++++++++++++++++++++++-------------------
>>  mm/page_isolation.c    |  45 +++++++++++---
>>  6 files changed, 127 insertions(+), 87 deletions(-)
>> 
> 
> Thanks for looking into this! Just a heads-up that -mm and -next contain
> some changes to memory hotplug code, whereby new pageblocks start out in
> MIGRATE_ISOLATE when onlining, until we're done with the heavy lifting.
> Might require some tweaks, similar to when isolating pageblocks.

Thanks for the heads-up. I've posted updated patch 5/5 for the -next as a reply
to the first one. It was a bit tricky to order everything correctly in
online_pages(), hopefully I avoided any deadlock.

> Will dive into this in the following days. What's you're general
> perception of performance aspects?

Thanks! I expect no performance change while no isolation is in progress, as
there are no new tests added in alloc/free paths. During page isolation there's
a single drain instead of once-per-pageblock, which is a benefit. But the
pcplists are effectively disabled for the whole of online_pages(),
offline_pages() or alloc_contig_range(), which will affect parallel page
allocator users. It depends on how long these operations take and how heavy the
parallel usage is, so I have no good answers. Might be similar to the current
periodic drain.