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 6A06AC4338F for ; Sat, 7 Aug 2021 01:11:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9757560FE7 for ; Sat, 7 Aug 2021 01:11:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9757560FE7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E2A466B006C; Fri, 6 Aug 2021 21:11:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB3828D0001; Fri, 6 Aug 2021 21:11:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7B2B6B0072; Fri, 6 Aug 2021 21:11:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id AA2616B006C for ; Fri, 6 Aug 2021 21:11:18 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 544091DADF for ; Sat, 7 Aug 2021 01:11:18 +0000 (UTC) X-FDA: 78446506236.34.190D355 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 0B89BB0053CC for ; Sat, 7 Aug 2021 01:11:16 +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=0gkM+UinbwtOqMmJysOWd9GVZtLlhJgV0HyjzW5szG4=; b=rB3exe9IYtV34ChTRLpSed1lNg 7QsbJaJRo0fSUK03lGDrWprgQvelPZ89Z2RzjVI/KXatwZsJYf8zIOG922SsakHPtpoRq6k6rXc0+ t5YnwvvrxL753nTuCSf95PruIDk94dDIm5raWp2QUTCrLM5hhqTrPegf1DhXPk9O7b1rxkgskqcT7 hTa8wEe7/VlImAUCS7hTcr8KXsEFE+Oftkr+yB0MhBWKBk9RqPkEc3eZQoWILMuvhx0XgmS3yTTBx BtBBy6E1sk3HqZMk1dMrxEmDQwkuILqfNneLVq6EQ3ixspqSlyyNvjucHZ0lNOOJSNYuNr/exHpw8 ivaZ87AA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mCArX-008l4C-Vz; Sat, 07 Aug 2021 01:10:59 +0000 Date: Sat, 7 Aug 2021 02:10:55 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: Zi Yan , Vlastimil Babka , David Hildenbrand , linux-mm@kvack.org, "Kirill A . Shutemov" , Mike Kravetz , Michal Hocko , John Hubbard , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/15] Make MAX_ORDER adjustable as a kernel boot time parameter. Message-ID: References: <20210805190253.2795604-1-zi.yan@sent.com> <0d374eed-cc52-a656-b338-1156782bdf7e@suse.cz> <6ae6cd92-3ff4-7ed3-b337-a4dfe33da1c@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ae6cd92-3ff4-7ed3-b337-a4dfe33da1c@google.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0B89BB0053CC Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rB3exe9I; dmarc=none; spf=none (imf25.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: ux365om461c1zcz588uadqp9hahqru5e X-HE-Tag: 1628298676-872828 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 Fri, Aug 06, 2021 at 01:27:27PM -0700, Hugh Dickins wrote: > On Fri, 6 Aug 2021, Zi Yan wrote: > > > > In addition, I would like to share more detail on my plan on supporting 1GB PUD THP. > > This patchset is the first step, enabling kernel to allocate 1GB pages, so that > > user can get 1GB THPs from ZONE_NORMAL and ZONE_MOVABLE without using > > alloc_contig_pages() or CMA allocator. The next step is to improve kernel memory > > fragmentation handling for pages up to MAX_ORDER, since currently pageblock size > > is still limited by memory section size. As a result, I will explore solutions > > like having additional larger pageblocks (up to MAX_ORDER) to counter memory > > fragmentation. I will discover what else needs to be solved as I gradually improve > > 1GB PUD THP support. > > Sorry to be blunt, but let me state my opinion: 2MB THPs have given and > continue to give us more than enough trouble. Complicating the kernel's > mm further, just to allow 1GB THPs, seems a very bad tradeoff to me. I > understand that it's an appealing personal project; but for the sake of > of all the rest of us, please leave 1GB huge pages to hugetlbfs (until > the day when we are all using 2MB base pages). I respect your opinion, Hugh. You, more than most of us, have spent an inordinate amount of time debugging huge page related issues. I also share your misgivings about the potential performance improvements for 1GB pages. They're too big for all but the most unusual of special cases. This hasn't been helped by the scarce number of 1GB TLB entries in Intel CPUs until very recently (and even those are hard to come by today). I do not think they are of interest for the page cache (as I'm fond of observing, if you have 7GB/s storage (eg the Samsung 980 Pro), you can take seven page faults per second). I am, however, of the opinion that 2MB pages give us so much trouble because they're so very special. Few people exercise those code paths and it's easy to break them without noticing. This is partly why I want to do arbitrary-order pages. If everybody is running with compound pages all the time, we'll see the corner cases often, and people other than Hugh, Kirill and Mike will be able to work on them. Now, I'm not planning on working on arbitrary-order anonymous pages myself. I think I have enough to deal with in the page cache & filesystems. But I'm happy to help out when I can be useful. I think 256kB pages are probably optimal at the moment for file-backed memory, so I'm not planning on exploring the space above PMD_ORDER myself. But there have already been some important areas of collaboration between the 1GB effort and the folio effort.