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 65951C4332F for ; Thu, 10 Nov 2022 16:32:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8382D6B0071; Thu, 10 Nov 2022 11:32:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C0DD6B0072; Thu, 10 Nov 2022 11:32:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 661586B0074; Thu, 10 Nov 2022 11:32:13 -0500 (EST) 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 523466B0071 for ; Thu, 10 Nov 2022 11:32:13 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F010CC0C60 for ; Thu, 10 Nov 2022 16:32:12 +0000 (UTC) X-FDA: 80118074904.23.B3A8ED9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 597F914000B for ; Thu, 10 Nov 2022 16:32:11 +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=NPEF063H+Y7JeJNfnAB1kp+fd1pLsT9ML+6VjdUPh7o=; b=mx+EY9COzoDzeuy2+0heRU2yNe yzX/vmiC19SUiPXxXDe3Mld28kvj/feSddm0YDw9iYaoR6cFptf4oO6yG82v/riN6Wpid4/0SRwQl zoOCHLqUuayVhzSFL6UbBwFSp6aZgG6Tb1dHoy0X72Ced80huuiy8/kMhkeaeH5LT47Jc4CoDZB1T mA+DweHo/jN0Rlhgnyde/Z0ueQJn3iMdcvqFEG2W66SIEdiQxy2oinLi/WkRa3UmvD8cFjFfFsRPH tp+x9oFo59yFei677vlB7qS8S/c2iCw3nDiN9eDPQftxhpdbchYaCJjS8hwCKiFm3t6iqIpCkjLS1 W2XpdHBQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1otASt-00CD9f-Ff; Thu, 10 Nov 2022 16:31:43 +0000 Date: Thu, 10 Nov 2022 16:31:43 +0000 From: Matthew Wilcox To: Linus Torvalds Cc: Hugh Dickins , Andrew Morton , Johannes Weiner , "Kirill A. Shutemov" , David Hildenbrand , Vlastimil Babka , Peter Xu , Yang Shi , John Hubbard , Mike Kravetz , Sidhartha Kumar , Muchun Song , Miaohe Lin , Naoya Horiguchi , Mina Almasry , James Houghton , Zach O'Keefe , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 4/3] mm,thp,rmap: handle the normal !PageCompound case first Message-ID: References: <5f52de70-975-e94f-f141-543765736181@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668097931; a=rsa-sha256; cv=none; b=cjlh3TCSzKQbqVl62tUZ9Qo3qihWucoJnYaPAapf1npIsNDlMHmRlfWbfFqcA39J/skrgG a+K4FU0TrFko6oKcbBahic6zCUeNzNsak1lmOVrkfrDv8V9vTTphdCSS+elIppKFW4n7Ck YGqwXCrOr4EVfv+K5fWtssdImGUb+2Q= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mx+EY9CO; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668097931; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NPEF063H+Y7JeJNfnAB1kp+fd1pLsT9ML+6VjdUPh7o=; b=em1yWbqiGUtMKVV2qtyvZK0LI3KEXSqof9txnyeHZLDcQLs9LXmE6ORScSR3xUtLn4Grot VBcqbxjLbP62+LfPZ0Qa671imtU02BcU3m+r6Bk5dMYxOO5Pg/JRvCieoBzqmdHKAsQmdr X+dLGQnH4uokOGjsZRGX/poTUSqYe4A= X-Stat-Signature: asxek6oq8rurztkpcxfjrgkzb1ph5opu X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mx+EY9CO; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Queue-Id: 597F914000B X-Rspamd-Server: rspam09 X-HE-Tag: 1668097931-730028 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 Wed, Nov 09, 2022 at 07:23:08PM -0800, Linus Torvalds wrote: > On Wed, Nov 9, 2022 at 6:18 PM Hugh Dickins wrote: > > > > Commit ("mm,thp,rmap: lock_compound_mapcounts() on THP mapcounts") > > propagated the "if (compound) {lock} else if (PageCompound) {lock} else > > {atomic}" pattern throughout; but Linus hated the way that gives primacy > > to the uncommon case: switch to "if (!PageCompound) {atomic} else if > > (compound) {lock} else {lock}" throughout. > > Side note, that 'compound' naming is also on my list of "I'm _really_ > not a fan". > > We actually have a completely different meaning for PageCompound() > than the meaning of 'compound' in the rmap functions, and those > functions literally mix those meanings if not on the same line, then > at least right next to each other. > > What 'rmap' actually means with 'compound' in the add/remove functions > is basically 'not PAGE_SIZE' as far as I can tell. Ah. I've been trying to understand what that 'compound' really means, and what the difference is to 'PageCompound()' and why we need both. Thanks! > One reason I find the "compound" name so horrifying is that it is used > very much for HUGETLB pages, which I don't think end up ever being > marked as PageCompund(), and which are - for various historical > reasons - doubly confusing because they use a "pte_t" to describe > themselves, even when they are actually using a "pmd_t" or a "pud_t" > to actually map the page. HugeTLB pages _are_ marked as Compound. There's some fairly horrific code to manually make them compound when they have to be allocated piecemeal (because they're 1GB and too large for the page allocator). > To make things more confusing, some places use PageHeadHuge() > instead (but the folio version of said test is called > "folio_test_hugetlb()", just so that nobody could possibly ever accuse > the HUGETLB code to have consistency). That one's my fault, but it's a reaction to all the times that I and others have got confused between PageHuge and PageTransHuge. I suppose we could do a big sed s/PageHuge/PageHugeTLB/, but I'm hopeful the entire hugetlb codebase is either converted to folios or unified with THP handling. > I do wish the HUGETLB case didn't use 'pte' for its notion of how > HUGETLB entries are mapped, but that's literally how HUGETLB is > designed: it started life as a larger last-level pte. > > It just means that it ends up being very confusing when from a page > table walk perspective, you're walking a pud or a pmd entry, and then > you see a 'pte_t' instead. Yes, one of the long-term things I want to try is making the hugetlb code use the pmd/pud types like the THP code does.