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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 19E19C433DB for ; Wed, 20 Jan 2021 14:27:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F73C23380 for ; Wed, 20 Jan 2021 14:27:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F73C23380 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F16CA6B0007; Wed, 20 Jan 2021 09:27:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA0C26B0008; Wed, 20 Jan 2021 09:27:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D41B66B000D; Wed, 20 Jan 2021 09:27:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id B95036B0007 for ; Wed, 20 Jan 2021 09:27:19 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7A1771EF1 for ; Wed, 20 Jan 2021 14:27:19 +0000 (UTC) X-FDA: 77726380998.11.lead68_1b135882755b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 6176B180F8B81 for ; Wed, 20 Jan 2021 14:27:19 +0000 (UTC) X-HE-Tag: lead68_1b135882755b X-Filterd-Recvd-Size: 6025 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Wed, 20 Jan 2021 14:27:18 +0000 (UTC) Received: by mail-ej1-f52.google.com with SMTP id gx5so14530693ejb.7 for ; Wed, 20 Jan 2021 06:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GkoyOR4GCbG3ynLuDWDdmAP5ksEvgcnDncmZjj1fgMM=; b=an5cja/qYdQGpAjEtPTDlH7M4BiW92BqboXSMssTNPV4yTjKD78MUD5pEtcL4HxxBn V/LZ/aoi8wlkrKsC8Qmg/qeRpOqO6Lc59buU1gR04o2c3slsze1h/DdHxyg39Lal1wwm J5BrNriuP70iDJRY2q8iuUHjmvvEU+rArKoGBYfILNJE0XzqViV6/UrZIGlk6hh1vt3Z UcO5hmOTFdXGBZFktmXXPChyN5Dt7ePCcUNR0/C44f7yXQIYPska3yhn7AscuXCZtO5D T9Qr4MLNFVfYa7eQjmjHJROH4PaCRUtdBjam1uR+qwsblSsnHUvuobpAb+hyYIHAx/i0 z98Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GkoyOR4GCbG3ynLuDWDdmAP5ksEvgcnDncmZjj1fgMM=; b=bhIWP9soNVFO6L2JSBof7gsPwqn0f6yUrwRHAmmm/f3wHW5aS2NF3/JmESUuIZHzoR R7GU7J2b6FU+UXJohtOlE51xIytTXItmrteUltioECi+XIA0oMc0fMxcp9swW3hF5s4M Wz5NfCq22RFIEQCWHdXT3NG1cwKJDtZIhBoBgoEwEte7CaTdS9wFs7/DKYRuGQlLkuP/ Rc6KwLANEwAdGN07d0w4dOLibzguOiEMrnkgr1cELxKX71AfoTqDA5RfSR42v3tLkLKZ 9aFpCNjtTrHnsnHUB9xuD9ijrPn5Ptf8DovYrItPRRPHtlFDH0E1Y9/Q1fzeENA8pJu+ 9DSQ== X-Gm-Message-State: AOAM532quSm0IKLu4jRHjp+16H6JlVFyoU5yb81JZHfggrsuKFUTpopU MEaNjIScpBxz0CW3MV93BkqajBnKgOVs39P/SjpBBg== X-Google-Smtp-Source: ABdhPJx5zFMlZW8Q/2uSKGMxlwI9VWUTvzWik3bYe1Wpdl5R67YaRP8DqOj41K+I/K735EdU0sRXLJ/NpBzmj3Ecvvs= X-Received: by 2002:a17:906:c5b:: with SMTP id t27mr6436494ejf.129.1611152837523; Wed, 20 Jan 2021 06:27:17 -0800 (PST) MIME-Version: 1.0 References: <20210120014333.222547-1-pasha.tatashin@soleen.com> <20210120014333.222547-9-pasha.tatashin@soleen.com> <20210120131400.GF4605@ziepe.ca> In-Reply-To: <20210120131400.GF4605@ziepe.ca> From: Pavel Tatashin Date: Wed, 20 Jan 2021 09:26:41 -0500 Message-ID: Subject: Re: [PATCH v6 08/14] mm/gup: do not migrate zero page To: Jason Gunthorpe Cc: LKML , linux-mm , Andrew Morton , Vlastimil Babka , Michal Hocko , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , Joonsoo Kim , mike.kravetz@oracle.com, Steven Rostedt , Ingo Molnar , Peter Zijlstra , Mel Gorman , Matthew Wilcox , David Rientjes , John Hubbard , Linux Doc Mailing List , Ira Weiny , linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 20, 2021 at 8:14 AM Jason Gunthorpe wrote: > > On Tue, Jan 19, 2021 at 08:43:27PM -0500, Pavel Tatashin wrote: > > On some platforms ZERO_PAGE(0) might end-up in a movable zone. Do not > > migrate zero page in gup during longterm pinning as migration of zero page > > is not allowed. > > > > For example, in x86 QEMU with 16G of memory and kernelcore=5G parameter, I > > see the following: > > > > Boot#1: zero_pfn 0x48a8d zero_pfn zone: ZONE_DMA32 > > Boot#2: zero_pfn 0x20168d zero_pfn zone: ZONE_MOVABLE > > > > On x86, empty_zero_page is declared in .bss and depending on the loader > > may end up in different physical locations during boots. > > > > Signed-off-by: Pavel Tatashin > > include/linux/mmzone.h | 4 ++++ > > mm/gup.c | 2 ++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > > index fc99e9241846..f67427a8f22b 100644 > > +++ b/include/linux/mmzone.h > > @@ -427,6 +427,10 @@ enum zone_type { > > * techniques might use alloc_contig_range() to hide previously > > * exposed pages from the buddy again (e.g., to implement some sort > > * of memory unplug in virtio-mem). > > + * 6. ZERO_PAGE(0), kernelcore/movablecore setups might create > > + * situations where ZERO_PAGE(0) which is allocated differently > > + * on different platforms may end up in a movable zone. ZERO_PAGE(0) > > + * cannot be migrated. > > * > > * In general, no unmovable allocations that degrade memory offlining > > * should end up in ZONE_MOVABLE. Allocators (like alloc_contig_range()) > > diff --git a/mm/gup.c b/mm/gup.c > > index 857b273e32ac..fdd5cda30a07 100644 > > +++ b/mm/gup.c > > @@ -1580,6 +1580,8 @@ static long check_and_migrate_cma_pages(struct mm_struct *mm, > > * of the CMA zone if possible. > > */ > > if (is_migrate_cma_page(head)) { > > + if (is_zero_pfn(page_to_pfn(head))) > > + continue; > > I think you should put this logic in is_pinnable_page() I thought about this, and it would code a little cleaner. But, the reason I did not is because zero_page is perfectly pinnable, it is not pinnable only when it is in a movable zone (and it should not be in a movable zones for other reasons as well), but that is another bug that needs to be resolved, and once that bug is resolved this condition can be removed from gup migration. Pasha > > Jason