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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 3A190C433ED for ; Thu, 6 May 2021 19:35:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA3486113E for ; Thu, 6 May 2021 19:35:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA3486113E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EC5F56B006C; Thu, 6 May 2021 15:35:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E75596B006E; Thu, 6 May 2021 15:35:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEFDA6B0070; Thu, 6 May 2021 15:35:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id AE68C6B006C for ; Thu, 6 May 2021 15:35:33 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6F25D181AEF1E for ; Thu, 6 May 2021 19:35:33 +0000 (UTC) X-FDA: 78111810546.33.65D3D40 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id 0E60C5001536 for ; Thu, 6 May 2021 19:35:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=+Gmd9WE9Bu2QYLvWpqKR/yYem0cFXFiMf/zwpkj95U8=; b=crQvOxVhfA0rYm1ruAKJBNw0xC xsM1t+SsJ5U1dOvsLom1VliGQksmvwhkFYj4n7ocfHyofPKeGYBDJFe7TYnq2YqoCPZFOp9Hi5yST 4FH25flkLwf/Lwe/+RCpeR/nmAkbyaM0SvaT/6ZA3du1X0I7kf4FyjORRo8wpB+6q2guCZ8DJU5gv abGYH78vgb/2DeTmQHYosKU2fazelARvJeX7jelqa1FilgXL4Ovy+pzWnv0m0qQ94W3S3HRu/HDqu DvLeYnQ9jgK+5VudN9eKZp/TM9hNoGEyJpw9FhDDQ01zRQCnF9I0oCHm83eSPFGW7r3nw8/YpGdhl 9IBGKFNQ==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lejha-0028sz-5z; Thu, 06 May 2021 19:30:34 +0000 Date: Thu, 6 May 2021 20:30:26 +0100 From: Matthew Wilcox To: David Hildenbrand 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 Subject: Re: [RFC PATCH 0/7] Memory hotplug/hotremove at subsection size Message-ID: <20210506193026.GE388843@casper.infradead.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e850dcb-c69a-188b-7ab9-09e6644af3ab@redhat.com> Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=crQvOxVh; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: 1eyaxkjxxbqnmqcic7pojggdoqfjfkjh X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0E60C5001536 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620329730-409371 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 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 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 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 know that for the initial implementation, we're going to rely on hints from the user to use 1GB pages, but it'd be nice to not do that.