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 C2C77C54798 for ; Thu, 7 Mar 2024 21:14:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D08B6B02BF; Thu, 7 Mar 2024 16:14:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3807B6B02C0; Thu, 7 Mar 2024 16:14:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 248A76B02C1; Thu, 7 Mar 2024 16:14:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1034C6B02BF for ; Thu, 7 Mar 2024 16:14:56 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BD2731C1447 for ; Thu, 7 Mar 2024 21:14:55 +0000 (UTC) X-FDA: 81871497750.08.3CC1EFB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 19D48180008 for ; Thu, 7 Mar 2024 21:14:52 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FPvouYrE; spf=none (imf24.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=1709846093; 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=drEPjzf7MwnPcjOKgoHDVW6gLYcrxm3YspYSG89Zqms=; b=u5fg79MKI0Y4AwfTeByxk5semEPwyRcrOsIEi8qiOlsSOMybnz6JkC2sNMOnFW4jr2kbNX fHSR+yXdtIGZj8v5YTkYjSx1IhR35cveB/trxCE+QhrtKoWhTPRYptbdCkJBOOnXO2mhrD snmZgpbkjrxZHz4/2hpg0LoxCcNWICE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FPvouYrE; spf=none (imf24.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709846093; a=rsa-sha256; cv=none; b=BW70BhPDUZqh3vu8GklXYB5eIdpA916ZcR2n8teDuDiFWEsedETmFYC0CPV5kVwv03TqNL QJPArsjXzOHE+QLNHwG9JNhGA9UlaPAtf9mTwYNqxzPbvkfIUh2yVgQVB1Bi0RMi5vzPIc //4FTWsRlUfWj//PgjJmd1CDAx0Yc2A= 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=drEPjzf7MwnPcjOKgoHDVW6gLYcrxm3YspYSG89Zqms=; b=FPvouYrEL5mBU8oaSvhRiDpSiD sk8ezor+9EB+fDRPSmfhFWPa4uCe0D8N5KUH76PEsVSkVFCQYGZ2uJ5zBKHMwzxn6YF4xm8c0px6E J9MGCiL3teoVJBjU2kElP7JwxeTlCJNbmwEoJb5pv444WxkTCqKZoHsbG2YDYQrqlTZ2ZnX8VrU/F EGoGEN71WOg9Ea9igyaE6bHsTIxCxVxPdp3dJ1ASDk9cPylXU6eYlMe77HCQjiRtFvulrZld8thiL W3nVPX9KEr+HGJILZiehAbJoZDMG4b3h+Nwwvo2tlJQPaOsyMfpmign9rEV+6268R79wMj3PxCG4c Xkwv+THQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1riL4k-00000009zS6-1zIX; Thu, 07 Mar 2024 21:14:50 +0000 Date: Thu, 7 Mar 2024 21:14:50 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: linux-mm@kvack.org, Oscar Salvador Subject: Re: [PATCH 0/5] Remove some races around folio_test_hugetlb Message-ID: References: <20240301214712.2853147-1-willy@infradead.org> <52599fd8-76dc-4d8f-b9f2-78146fc7a518@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 19D48180008 X-Rspam-User: X-Stat-Signature: 4xfqc6n93sjjqpf4xgjkui8rszwdmh9o X-Rspamd-Server: rspam01 X-HE-Tag: 1709846092-684863 X-HE-Meta: U2FsdGVkX1+5EWn7fPKM9VuyO2iZ4/Gjh6B5Y1wuG2BOHQCIQqQLqbgiQRNDVvutPukCDNiJgk4PTyUaXxCDyzcvDFZcTTo/rYuioSyJ2LYyI3HElOfaCc/XQfTC3/1+U3m3BkYIm90k6gFo/D99m/ok4ar+iIvdJvQa8SPAqo+P5TQ4ltUu3MPJcj5wZnZbNgZqz4LiXxomlKX82A6ALdkuF8/ecEPvPrZbxDAuE4HTzwaAJLLVpURZ2/M5c7hS7Gdkd/76M32kAkVBMs80BVFCfklb6LTSRLu55tHFcFWRbOeiIX58x3JrVy/UV+/bgTDgUZFLvsu2oI627LQOUrvXMt3/f/4sZVhHjTcBJedC/crdo5PJi4oLMplgswCvE8dyYZZPJk0gpGZZ0pabPh7r9CjHFTJJNxCwgCyXxcU8YKjRmlQoRz9cKs9gkLAafduw3HqxA1g/5I4sjdc58mv7SIippG4e799QU4C3SxQF8VmLIOZ5xy35QElNz3EX1baSLey6E7oMApbwVxnzladAGS0eNJjNyLtXJs8FDsLUFIbKSbDMryDTVlGUdLj9OQLXbm+2TypF3MldhBocvUmLYxiJPGE4ZAPsUnu+NPyAA+CPGc07cHaOp0BMGOuWEayXRVK9uXVMjwH+nXaEnjwkCfdgy6LlMb9nQ3hpd5UT8+XMr8amJU6YW7zkZua1/r/4TTH8aEabuJp7bFfybNDAjJ/ntMMTAvVI0sz57WZxs76NqhgmXtmPzyg/SoO2wX1OB53evOkLOu5Ra2NpBm9ScvMkzBc4+0mHh76F/SXf5lRek1jhgpgZxN2oVapD853sPa/qLSek2l0HfvVGOr9zzMd2jHo7GtHhegSrx0nqSyy+LSx+cJxuS/xj9zMB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Mar 07, 2024 at 10:20:15AM +0100, David Hildenbrand wrote: > > > > IOW: > > > > > > > > word page0 page1 > > > > 0 flags flags > > > > 1 lru.next head > > > > 2 lru.prev entire_mapcount + gap > > > > 3 mapping nr_pages_mapped + gap / hugetlb_id > > > > 4 index pincount + nr_pages > > > > 5 private unused > > > > 6 mapcount+refcount mapcount+refcount(0) > > > > 7 memcg_data - > > > > > > > > or on 32-bit > > > > > > > > word page0 page1 > > > > 0 flags flags > > > > 1 lru.next head > > > > 2 lru.prev entire_mapcount > > > > 3 mapping nr_pages_mapped / hugetlb_id > > > > 4 index pincount > > > > 5 private unused > > > > 6 mapcount mapcount > > > > 7 refcount refcount > > > > 8 memcg_data - > > > > 9+ virtual? last_cpupid? whatever > > > > How about this layout? > > > > @@ -350,8 +350,13 @@ struct folio { > > unsigned long _head_1; > > unsigned long _folio_avail; > > /* public: */ > > - atomic_t _entire_mapcount; > > - atomic_t _nr_pages_mapped; > > + union { > > + unsigned long _hugetlb_id; > > + struct { > > + atomic_t _entire_mapcount; > > + atomic_t _nr_pages_mapped; > > + }; > > + }; > > atomic_t _pincount; > > #ifdef CONFIG_64BIT > > unsigned int _folio_nr_pages; > > > > That keeps _folio_avail as, well, available. It puts _hugetlb_id in > > the same bits as ->mapping. It continues to leave ->private unused > > on 64-bit. I think this does everything we want? > > _entire_mapcount is (still) used for hugetlb folios. Oh, duh, of course it is. I thought we used page[0].mapcount for them, but we don't and shouldn't. I suppose we could use a magic value for page[0].mapcount to indicate hugetlb, but that'd make page_mapcount() more complex. > With the total mapcount in place, I was thinking about renaming it to > "_pmd_mapcount" and stop using it for hugetlb folios, just like we'd not be > using _nr_pages_mapped for hugetlb folios. > > [I also thought about moving the _pmd_mapcount to another subpage, where > we'd also have a _pud_mapcount in the future; but again, stuff for the > future] > > Until then, wouldn't _hugetlb_id be problematic here? [I could move > _entire_mapcount/_pmd_mapcount later I guess] New idea then, how about simply: unsigned long _flags_1; unsigned long _head_1; - unsigned long _folio_avail; + unsigned long _hugetlb_id; We have to check the various other users of struct page to see what we might conflict with. slab: struct list_head slab_list; void *freelist; /* first free object */ struct rcu_head rcu_head; ptdesc: struct rcu_head pt_rcu_head; struct list_head pt_list; pgtable_t pmd_huge_pte; So it's always used as a pointer (or a pointer in disguise). That means that either using a pointer to something hugetlb-related or a value like (void *)-2 will be unambiguous. It'll just be something to document in each of the types split from struct page.