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=-7.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 C7AEAC432BE for ; Fri, 6 Aug 2021 16:16:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12CC0611C5 for ; Fri, 6 Aug 2021 16:16:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 12CC0611C5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7F5CC8D0001; Fri, 6 Aug 2021 12:16:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A4F56B0071; Fri, 6 Aug 2021 12:16:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66C478D0001; Fri, 6 Aug 2021 12:16:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 4A0156B006C for ; Fri, 6 Aug 2021 12:16:48 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5B0D11823DA93 for ; Fri, 6 Aug 2021 16:16:46 +0000 (UTC) X-FDA: 78445159212.07.BF67125 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id EBEA730095FC for ; Fri, 6 Aug 2021 16:16:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628266605; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7xHSpnJtP+yised83clbZYxtS0H9GH4PHvNYgDaicDE=; b=PTqcLR89Ab9Oh+HClyPJNThCa2xYoZQx/qnhQybHGfnZ2JB/B7VpbLaGmdSv3R/EDUZBmI 3FHrpPvft11j8eaoFERfcVZYG00fR66V/8SrJg9TlWnpKaL94S3gxKzqx9W3hpY3Dw/YR+ GRHZieoDeRMaizkdr0Cq2fzT/zePUug= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-335-a1EF4KOOOHawjvaLkt6IQg-1; Fri, 06 Aug 2021 12:16:44 -0400 X-MC-Unique: a1EF4KOOOHawjvaLkt6IQg-1 Received: by mail-wr1-f69.google.com with SMTP id r14-20020a5d4e4e0000b029015409d80a01so3309964wrt.12 for ; Fri, 06 Aug 2021 09:16:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=7xHSpnJtP+yised83clbZYxtS0H9GH4PHvNYgDaicDE=; b=S2nnO4huDasE5XehaMUIVUu+/JdqZJ8Dm51GAOfvY8v+jfCeC+xm19Z73g59lAtZz9 Fgiz1bNlNGpd/yBeYPr19CZCGcTxXSKD26Npe2RTO9yj1iLerpeGaySnM1Ff1tgcwykg pQzoWKOEPeqBRirGmgBZNwb7T5wGjexL8iy+RnvgD4XKfmjPHKaFBdKTr9BH+ptDrg2n AMFjNVDpqxSgBijnCnpFEz839oJygDaeMs9eh/DKaTLnRr4dGNPKgiebmpqiiYDU8YXt b4fbSXdsK2zzDHINjNJPYm/D9pOrWNy6TZTUC4OmCTzLyz5detYm8G7dGhzMueR0pKRt OixA== X-Gm-Message-State: AOAM530Ze6ER7r22tWOcr8oIr1ijzwLUeSvQiu2tTpkN4Bz/4TlC3sHs BXcM6IcnpPpd8xapcui349XdAbbI76v65jC88M9qOYciKAAP1ljKS4nrKp6MVaBeSj61ZNcCLVI HpKD6qAru0zo= X-Received: by 2002:a5d:6991:: with SMTP id g17mr11763543wru.253.1628266602895; Fri, 06 Aug 2021 09:16:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUzbz49pY0WWOS9RdZpe8ZwJnExFSL1NBYRZ86E2lQxy38Fgqx6EbXawHcNewWTxh8/qjmGg== X-Received: by 2002:a5d:6991:: with SMTP id g17mr11763520wru.253.1628266602638; Fri, 06 Aug 2021 09:16:42 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6104.dip0.t-ipconnect.de. [91.12.97.4]) by smtp.gmail.com with ESMTPSA id z3sm12634740wmf.6.2021.08.06.09.16.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Aug 2021 09:16:42 -0700 (PDT) To: Vlastimil Babka , Zi Yan , linux-mm@kvack.org Cc: Matthew Wilcox , "Kirill A . Shutemov" , Mike Kravetz , Michal Hocko , John Hubbard , linux-kernel@vger.kernel.org, Mike Rapoport References: <20210805190253.2795604-1-zi.yan@sent.com> <40982106-0eee-4e62-7ce0-c4787b0afac4@suse.cz> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC PATCH 00/15] Make MAX_ORDER adjustable as a kernel boot time parameter. Message-ID: <72b317e5-c78a-f0bc-fe69-f82261ec252e@redhat.com> Date: Fri, 6 Aug 2021 18:16:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <40982106-0eee-4e62-7ce0-c4787b0afac4@suse.cz> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PTqcLR89; spf=none (imf03.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EBEA730095FC X-Stat-Signature: qmf84x9t476ekqs4nm35eu6k4q6w5qyt X-HE-Tag: 1628266605-307321 Content-Transfer-Encoding: quoted-printable 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 06.08.21 17:36, Vlastimil Babka wrote: > On 8/5/21 9:02 PM, Zi Yan wrote: >> From: Zi Yan >=20 >> Patch 3 restores the pfn_valid_within() check when buddy allocator can= merge >> pages across memory sections. The check was removed when ARM64 gets ri= d of holes >> in zones, but holes can appear in zones again after this patchset. >=20 > To me that's most unwelcome resurrection. I kinda missed it was going a= way and > now I can't even rejoice? I assume the systems that will be bumping max= _order > have a lot of memory. Are they going to have many holes? What if we jus= t > sacrificed the memory that would have a hole and don't add it to buddy = at all? I think the old implementation was just horrible and the description we=20 have here still suffers from that old crap: "but holes can appear in=20 zones again". No, it's not related to holes in zones at all. We can have=20 MAX_ORDER -1 pages that are partially a hole. And to be precise, "hole" here means "there is no memmap" and not "there=20 is a hole but it has a valid memmap". But IIRC, we now have under SPARSEMEM always a complete memmap for a=20 complete memory sections (when talking about system RAM, ZONE_DEVICE is=20 different but we don't really care for now I think). So instead of introducing what we had before, I think we should look=20 into something that doesn't confuse each person that stumbles over it=20 out there. What does pfn_valid_within() even mean in the new context?=20 pfn_valid() is most probably no longer what we really want, as we're=20 dealing with multiple sections that might be online or offline; in the=20 old world, this was different, as a MAX_ORDER -1 page was completely=20 contained in a memory section that was either online or offline. I'd imagine something that expresses something different in the context=20 of sparsemem: "Some page orders, such as MAX_ORDER -1, might span multiple memory=20 sections. Each memory section has a completely valid memmap if online.=20 Memory sections might either be completely online or completely offline.=20 pfn_to_online_page() might succeed on one part of a MAX_ORDER - 1 page,=20 but not on another part. But it will certainly be consistent within one=20 memory section." Further, as we know that MAX_ORDER -1 and memory sections are a power of=20 two, we can actually do a binary search to identify boundaries, instead=20 of having to check each and every page in the range. Is what I describe the actual reason why we introduce pfn_valid_within()=20 ? (and might better introduce something new, with a better fitting name?) --=20 Thanks, David / dhildenb