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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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 B4EA3C433ED for ; Thu, 6 May 2021 19:38:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 45A376113E for ; Thu, 6 May 2021 19:38:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 45A376113E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B18D16B006E; Thu, 6 May 2021 15:38:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF0356B0070; Thu, 6 May 2021 15:38:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 968FF6B0071; Thu, 6 May 2021 15:38:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 7B0B06B006E for ; Thu, 6 May 2021 15:38:44 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 36728180AD837 for ; Thu, 6 May 2021 19:38:44 +0000 (UTC) X-FDA: 78111818568.38.625003D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 317EA200025D for ; Thu, 6 May 2021 19:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620329923; 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=mD9rk0OEj0XYhxeQH5IDJPNbrX+PSqo6PoFdlh4Fuj4=; b=BPAD6O3l9g7o2RiF0PCpsQx/VHW8+cqU8AnJeERpuOobj02DP6YcC9bkyj/aXj/t2k6d3w mV69N6Ft6xP/K8IDRA2lTHYc/UQImxgWK7bpKtJIHLSg355cIEdtKNJKP9bH3mnlJ39k6w UfLHeUZX62Xp99+6yTRn+MPcQXJDSAU= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-104-B7q4FU4ZPseJQac_5l8j1Q-1; Thu, 06 May 2021 15:38:40 -0400 X-MC-Unique: B7q4FU4ZPseJQac_5l8j1Q-1 Received: by mail-wm1-f69.google.com with SMTP id s66-20020a1ca9450000b0290149fce15f03so3024478wme.9 for ; Thu, 06 May 2021 12:38:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=mD9rk0OEj0XYhxeQH5IDJPNbrX+PSqo6PoFdlh4Fuj4=; b=RdbSmApd25urFJiOzJGRakIglnsQbdhiLOpSm/djnWpthzSSMDJg4CuecWO6gFn+Kp okBc7RNp+OOKrWFgp6JReBCFKnqo9JxsXA73jLCTULxw+g2GNCDx0ClEY6P7fyZE5k6a px4+L79WSwMe/Alm58W+XUI/e7nS2OAFCxxo4zeZ9GjBYfaXWNxj/JZnaA1aABp7MBtP N58+rOoVc/dIY4gWQReSAE4CFfrm5aTLwy9ll51CNRyOyXfh7FFdUn/QMnWJk31snLmr IYLpPwRUUefJIJy5aR0NNTcOTYqnUOC/TeUu5DVKujSwXsQOHe7HsjCQyziVqeAVJlKB fk4g== X-Gm-Message-State: AOAM530pIng0GnDiw6Nv9iP09/TLpyFicyEt+K7v0CfylDLfK3E32qxQ ngfBdB5nrCo32D7nMcEwsppdnE770KThxqBId7UUeSZ//kcZtSsCQXbpQ3nJVtovsPEy43QBvXw qRh0arJgRuee3RFB0vH2WHYnMSKBOm91EU/+QY7FD9n6Araeozkgnzwt9vac= X-Received: by 2002:a5d:51d2:: with SMTP id n18mr7392216wrv.69.1620329919164; Thu, 06 May 2021 12:38:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOC06i3MicUKjMNEqxEnGDL/rTRmiJEviad77ONpxe7ogE7ETHVYywYhvhoyD41LPb0MdTmQ== X-Received: by 2002:a5d:51d2:: with SMTP id n18mr7392182wrv.69.1620329918917; Thu, 06 May 2021 12:38:38 -0700 (PDT) Received: from [192.168.3.132] (p5b0c64ae.dip0.t-ipconnect.de. [91.12.100.174]) by smtp.gmail.com with ESMTPSA id q10sm4494733wmc.31.2021.05.06.12.38.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 May 2021 12:38:38 -0700 (PDT) Subject: Re: [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size To: Matthew Wilcox Cc: Zi Yan , Oscar Salvador , Michael Ellerman , Benjamin Herrenschmidt , Thomas Gleixner , x86@kernel.org, Andy Lutomirski , "Rafael J . Wysocki" , Andrew Morton , Mike Rapoport , Anshuman Khandual , Michal Hocko , Dan Williams , Wei Yang , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org References: <20210506152623.178731-1-zi.yan@sent.com> <9D7FD316-988E-4B11-AC1C-64FF790BA79E@nvidia.com> <3a51f564-f3d1-c21f-93b5-1b91639523ec@redhat.com> <16962E62-7D1E-4E06-B832-EC91F54CC359@nvidia.com> <3A6D54CF-76F4-4401-A434-84BEB813A65A@nvidia.com> <0e850dcb-c69a-188b-7ab9-09e6644af3ab@redhat.com> <20210506193026.GE388843@casper.infradead.org> From: David Hildenbrand Organization: Red Hat Message-ID: Date: Thu, 6 May 2021 21:38:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210506193026.GE388843@casper.infradead.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 317EA200025D X-Stat-Signature: 3r3gqiht6ww8kw5n7nbj1j55qzg1uq7c Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BPAD6O3l; spf=none (imf18.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620329925-733152 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.05.21 21:30, Matthew Wilcox wrote: > On Thu, May 06, 2021 at 09:10:52PM +0200, David Hildenbrand wrote: >> I have to admit that I am not really a friend of that. I still think our >> target goal should be to have gigantic THP *in addition to* ordinary THP. >> Use gigantic THP where enabled and possible, and just use ordinary THP >> everywhere else. Having one pageblock granularity is a real limitation IMHO >> and requires us to hack the system to support it to some degree. > > You're thinking too small with only two THP sizes ;-) I'm aiming to Well, I raised in my other mail that we will have multiple different use cases, including multiple different THP e.g., on aarch64 ;) > support arbitrary power-of-two memory allocations. I think there's a > fruitful discussion to be had about how that works for anonymous memory -- > with page cache, we have readahead to tell us when our predictions of use > are actually fulfilled. It doesn't tell us what percentage of the pages Right, and I think we have to think about a better approach than just increasing the pageblock_order. > allocated were actually used, but it's a hint. It's a big lift to go from > 2MB all the way to 1GB ... if you can look back to see that the previous > 1GB was basically fully populated, then maybe jump up from allocating > 2MB folios to allocating a 1GB folio, but wow, that's a big step. > > This goal really does mean that we want to allocate from the page > allocator, and so we do want to grow MAX_ORDER. I suppose we could > do somethig ugly like > > if (order <= MAX_ORDER) > alloc_page() > else > alloc_really_big_page() > > but that feels like unnecessary hardship to place on the user. I had something similar for the sort term in mind, relying on alloc_contig_pages() (and maybe ZONE_MOVABLE to make allocations more likely to succeed). Devil's in the details (page migration, ...). -- Thanks, David / dhildenb