From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C555C4727C for ; Tue, 22 Sep 2020 14:37:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAEFE2399A for ; Tue, 22 Sep 2020 14:37:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAEFE2399A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D6265900092; Tue, 22 Sep 2020 10:37:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A34C890009B; Tue, 22 Sep 2020 10:37:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AC91900097; Tue, 22 Sep 2020 10:37:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 5B129900092 for ; Tue, 22 Sep 2020 10:37:22 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 211EE824999B for ; Tue, 22 Sep 2020 14:37:22 +0000 (UTC) X-FDA: 77290950324.30.wave83_1c0a3a52714e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 028C5180B3AA7 for ; Tue, 22 Sep 2020 14:37:21 +0000 (UTC) X-HE-Tag: wave83_1c0a3a52714e X-Filterd-Recvd-Size: 4047 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 14:37:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 03AE1B0B3; Tue, 22 Sep 2020 14:37:57 +0000 (UTC) From: Vlastimil Babka To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Michal Hocko , Pavel Tatashin , David Hildenbrand , Oscar Salvador , Joonsoo Kim , Vlastimil Babka Subject: [PATCH 0/9] disable pcplists during memory offline Date: Tue, 22 Sep 2020 16:37:03 +0200 Message-Id: <20200922143712.12048-1-vbabka@suse.cz> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: As per the discussions [1] [2] this is an attempt to implement David's suggestion that page isolation should disable pcplists to avoid races wit= h page freeing in progress. This is done without extra checks in fast paths, as explained in Patch 9. The repeated draining done by [2] is then no longer needed. Previous version (RFC) is at [3]. The RFC tried to hide pcplists disabling/enabling into page isolation, bu= t it wasn't completely possible, as memory offline does not unisolation. Micha= l suggested an explicit API in [4] so that's the current implementation and= it seems indeed nicer. Once we accept that page isolation users need to do explicit actions arou= nd it depending on the needed guarantees, we can also IMHO accept that the curr= ent pcplist draining can be also done by the callers, which is more effective= . After all, there are only two users of page isolation. So patch 7 does effectively the same thing as Pavel proposed in [5], and patches 8-9 impl= ement stronger guarantees only for memory offline. If CMA decides to opt-in to = the stronger guarantee, it's easy to do so. Patches 1-6 are preparatory cleanups for pcplist disabling. Patchset was briefly tested in QEMU so that memory online/offline works, = but I haven't done a stress test that would prove the race fixed by [2] is eliminated. Note that patch 9 could be avoided if we instead adjusted page freeing in= shown in [6], but I believe the current implementation of disabling pcplists is= not too much complex, so I would prefer this instead of adding new checks and longer irq-disabled section into page freeing hotpaths. [1] https://lore.kernel.org/linux-mm/20200901124615.137200-1-pasha.tatash= in@soleen.com/ [2] https://lore.kernel.org/linux-mm/20200903140032.380431-1-pasha.tatash= in@soleen.com/ [3] https://lore.kernel.org/linux-mm/20200907163628.26495-1-vbabka@suse.c= z/ [4] https://lore.kernel.org/linux-mm/20200909113647.GG7348@dhcp22.suse.cz= / [5] https://lore.kernel.org/linux-mm/20200904151448.100489-3-pasha.tatash= in@soleen.com/ [6] https://lore.kernel.org/linux-mm/3d3b53db-aeaa-ff24-260b-36427fac9b1c= @suse.cz/ Vlastimil Babka (9): 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: simplify pageset_update() mm, page_alloc: make per_cpu_pageset accessible only after init mm, page_alloc: cache pageset high and batch in struct zone mm, page_alloc: move draining pcplists to page isolation users mm, page_alloc: drain all pcplists during memory offline mm, page_alloc: optionally disable pcplists during page isolation include/linux/gfp.h | 1 + include/linux/mmzone.h | 8 ++ include/linux/page-isolation.h | 2 + mm/internal.h | 4 + mm/memory_hotplug.c | 27 +++-- mm/page_alloc.c | 190 ++++++++++++++++++--------------- mm/page_isolation.c | 26 ++++- 7 files changed, 152 insertions(+), 106 deletions(-) --=20 2.28.0