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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71863CA0FE5 for ; Fri, 1 Sep 2023 16:13:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 781638D001B; Fri, 1 Sep 2023 12:13:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 731318D0002; Fri, 1 Sep 2023 12:13:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F8E78D001B; Fri, 1 Sep 2023 12:13:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 50E938D0002 for ; Fri, 1 Sep 2023 12:13:41 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1FA3A80298 for ; Fri, 1 Sep 2023 16:13:41 +0000 (UTC) X-FDA: 81188524242.11.EA54A84 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id DFED11C0039 for ; Fri, 1 Sep 2023 16:13:34 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Dh9+zxZe; dmarc=none; spf=none (imf18.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693584818; h=from:from:sender: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:dkim-signature; bh=NSkOr/qzarOgeHRQXx2jXIFi81Mb5b1Le+e/GncXZHA=; b=gmxioIGX72l+63TRnwXQW+FerP8PdKiOV5TSgCN7mLMUbTqkmExob0ckt0Gdpqou+XVDe6 xKn+8SSM5z1bbHHN2h5NC6TB0fG1JqGkTyAqVfAVGysJlLLh1UHqI6cg/sPA5ZVKl3kZL0 hRyzFmQAsHh+NGMjW/x9quMR6LrUNyM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Dh9+zxZe; dmarc=none; spf=none (imf18.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693584818; a=rsa-sha256; cv=none; b=mHe5rPyokPaPkYNpJDKc3Sx3nXMVdOLBtLLqj671WWVD9wr8K1D7gFfKo3fQYG9GQqPtu7 rN5WjMWPT2i95mRxuSp+peHl31CZubwTZWZLzdHHpDWDCX0RvrgTs0dn3OyQkvotCYcTiP W1ledIVQpEVKJJRi6RvvhM3TIn1+wvs= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=NSkOr/qzarOgeHRQXx2jXIFi81Mb5b1Le+e/GncXZHA=; b=Dh9+zxZeSkMxui8dMapRCvNdfI p7UDpJwmo7AUHWD43+f8a94hjk+SnKBxZsP9IR4Vivk91PzA9uKmlTnlWguv3XEJK0X5N/2JZrcfT XN0jnAPFvrJVDeQohg9wFOOQOshNzfH8FzFYmyZjb4axtcEqM3atDc/42sZxgCEU0rjBcO+y6N1OZ iDPoToPEnjoXVmpogsRY93QGl5EB3kuIKY+HoMhfF0BK//pynz3jzdxU8W47N6FuwjVCVZ2ywUn2X dwlxOtSi9R+of3T5POCDiUc2osBTb6D3pP+Rh4y3FGh95kTVDwzdJFpIIUex4kWqeabsR8uIhTW9Y h1WLEilw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qc6ll-008T48-Jt; Fri, 01 Sep 2023 16:13:13 +0000 Date: Fri, 1 Sep 2023 17:13:13 +0100 From: Matthew Wilcox To: Yang Shi Cc: David Hildenbrand , "Huang, Ying" , Ryan Roberts , Andrew Morton , Yin Fengwei , Yu Zhao , Catalin Marinas , Anshuman Khandual , Zi Yan , Luis Chamberlain , Itaru Kitayama , "Kirill A. Shutemov" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5 3/5] mm: LARGE_ANON_FOLIO for improved performance Message-ID: References: <20230810142942.3169679-1-ryan.roberts@arm.com> <20230810142942.3169679-4-ryan.roberts@arm.com> <87v8dg6lfu.fsf@yhuang6-desk2.ccr.corp.intel.com> <5c9ba378-2920-4892-bdf0-174e47d528b7@arm.com> <87cyz43s63.fsf@yhuang6-desk2.ccr.corp.intel.com> <4e14730b-4e4c-de30-04bb-9f3ec4a93754@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DFED11C0039 X-Stat-Signature: qdpgndkb35gjqp1at361zq7e7studisg X-HE-Tag: 1693584814-442170 X-HE-Meta: U2FsdGVkX1+sMSQtzjAiYN9ewYQmRzpAHqBIMbLMKKkrTMsWU9iOELx+RadraMUO6NcKRptp8rbnNKm7EDEyC7SqgmN94mReWB8WFkfQGdbg5yPlJZfnCYzi2YEUpO/t/k45kc1bXMe4SKz8OF9/iCgNAAq3BBmEa2MzR2+aafWCDWC6AFBlCQvCm03RSoAjTTJ2K4GsneS/cJCyOVrhmt7gTmy2sIH0/KDWYmfInCgZUtE7NhTM0rEvQsbL2+D9S21Jr78Ofu4+ZE6j+4xIwvQHWQ2rgVfCioKjYAoyvV13Wolrnmabys6dsVea2fTEanhdDRLCePcGVC+Go2FJsg0PvFh7DwL5H5riUGGHr84O/YqIZAhoYGKlJtEG7Fh/gY1kcUvjgP3qQoJ/VB5dcsET+exISn/oc2eVZ64UWIYFwooUkaJbvzPj06DSHck0jMx5+PUYLbFaGNcAG7movTstRcGJRq9ag4oyg1sw5lfaSSZsHD6pWJnMUkvG1uS3ciensjiNjTT2QxDMMH5zEHDRuPFsXxtC3N5Q9hsmUQsH+H77KDemrUluWD4vQyKff90K5RtyfN66TQPoufgybWsjPR4eZP9XmqfX8Wsj6cbyfSb14mkeOMnVzRtYWoUrwvMDLPowKHASHFGqy5nprIXeD/x7zPha2Tfq0koukhR/+flOwwTstAEe+F/ggMGYxXNolqJr2qr29Kr0iN2XCJB9DUmb4Oz9Zhqg2AhtvgSRblFdlQUI/jiQ1VDHD9rkbk8x5Sil5uZJJ3UySuFG0SUxoZn6CzbJlTAAW9rqhKq77beY17zzXgbOEM5HpEYMWeO56oQ0m24sYv81lkgfwnHe8BNjROP9FwoPsyLraeeAEa0FDxqax0WhnUp0s5igbY/DjsBTsCYURY91ZCT29m2/2TRi3/uga4nJPIR2NpnFo45jL/8UtvNSaU2GgQ/F5kgQIMOzXb0ussY5VPg yHbC7T7K 7GqzkW0LhUlX5s3GSLRMSuLUpZlH1eIqMQ5waYlpbf+Vtnc1XS+jlt7s+OL9K1IGfYYU7t/RzkfwU/8EJp0pzdY5SLFhWuXTilJnhXeal/FDNqIBVnMxyzbWnv9nWGTt8wS/gt2N2FzX8Z0u+EeQVyAhyEKwUBiBmv5DJNtMTFkD/EN6CbVRNZI4cKsp7ibSR7C4514Et1AstmrFXj0/4BWOq+0yr+XgbCTpFQLbdN+dN81eRApOxiugRG4lm+ZVmswOV5GDbP5s7ltuX9zBuLGJi8w== 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, Aug 31, 2023 at 10:15:09AM -0700, Yang Shi wrote: > On Thu, Aug 31, 2023 at 12:57 AM David Hildenbrand wrote: > > Let's talk about that in a bi-weekly MM session. (I proposed it as a > > topic for next week). > > > > As raised in another mail, we can then discuss > > * how we want to call this feature (transparent large pages? there is > > the concern that "THP" might confuse users. Maybe we can consider > > "large" the more generic version and "huge" only PMD-size, TBD) > > I tend to agree. "Huge" means PMD-mappable (transparent or HugeTLB), > "Large" means any order but less than PMD-mappable order, "Gigantic" > means PUD mappable. This should incur the least confusion IMHO. "Large" means any order > 0. The limitation to <= PMD_ORDER is simply because I don't want to go through the whole VM and fix all the places that assume that pmd_page() returns a head page. The benefit to doing so is quite small, and the work to achieve it is quite large. The amount of work needed should decrease over time as we convert more code to folios, so deferring it is the right decision today. But nobody should have the impression that large folios are smaller than PMD size, nor even less than or equal. Just like they shouldn't think that large folios depend on CONFIG_TRANSPARENT_HUGEPAGE. They do today, but that's purely an implementation detail that will be removed eventually. > > I think there *really* has to be a way to disable it for a running > > system, otherwise no distro will dare pulling it in, even after we > > figured out the other stuff. > > TBH I really don't like to tie large folio to THP toggles. THP > (PMD-mappable) is just a special case of LAF. The large folio should > be tried whenever it is possible ideally. But I do agree we may not be > able to achieve the ideal case at the time being, and also understand > the concern about regression in early adoption, so a knob that can > disable large folio may be needed for now. But it should be just a > simple binary knob (on/off), and should not be a part of kernel ABI > (temporary and debugging only) IMHO. Best of luck trying to remove it after you've shipped it ... we've never been able to remove any of the THP toggles, only make them more complicated. > One more thing we may discuss is whether huge page madvise APIs should > take effect for large folio or not. They already do for file large folios; we listen to MADV_HUGEPAGE and attempt to allocate PMD_ORDER folios for faults.