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 04ED8C001E0 for ; Wed, 16 Aug 2023 12:05:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7310A280015; Wed, 16 Aug 2023 08:05:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E03F8D0001; Wed, 16 Aug 2023 08:05:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CF4D280015; Wed, 16 Aug 2023 08:05:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4B7C68D0001 for ; Wed, 16 Aug 2023 08:05:42 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 193C3C012C for ; Wed, 16 Aug 2023 12:05:42 +0000 (UTC) X-FDA: 81129838524.16.9D34C41 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 8025C1C0032 for ; Wed, 16 Aug 2023 12:05:38 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KAz903Jc; 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; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692187538; a=rsa-sha256; cv=none; b=LSUiQ6bQbM85HP1rEF74tSTLKncwtC9WIj1uTU8nWurS3OLbgd/YDfd1Bv92GLUSH4YXD1 tsDfrTWphCpEY0N792diZQh5C95+iLRalM4SIo2m0Xkkjt7y2uTUst+gBV1ZGqhh8rgpoH 7iqmrIDGoZ/iRjusy6NFGw6L1h16XTE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KAz903Jc; 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; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692187538; 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=96x4loGaNUixmyh7uTKcw82R2aq4GTzQxVccob+Q9PI=; b=GVB//DUo8U3phciA19sXFStJHmu3cwMkmdi4eCyVEwOsra1BxwUCjDp6uGX8PvVRH3MWtu 8Sb9uXOnGT2y41wCWOvThyY9rYWt2pLXtq34o14iSFFoFeopmzMSnQkbLqm8eIs/6b5MBn +RpsWJKjm2xh1V18R2F9svRt0szuor4= 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=96x4loGaNUixmyh7uTKcw82R2aq4GTzQxVccob+Q9PI=; b=KAz903JcvTLuiQ0fDYAEplCiiR N286TDjnVBOLlHyNg82P/uJHG7uIlAEj3NLJz/096BJ2bWuZttLYYBfDRICOibJNhcrrqYeUj86xx zfLfdqdIaif0QbdWnSr1x4kJ9Fr8JsbfNh3hduyeeVznEl9JLaii17se2DMDGGRyZA0Vkg6ONEMgw Psek39xuvvosd7QlZos+gAU8g1bCa7in6FvXOPq6Ldy97mgkCNeUwejlhxOuCe30tgsz93R1A0N2u YAsAujVxJKGOTyXF/wLeW+tOcc8oT3s6Jr/awIdkdjqJPUdpMocdyJf0PT83ENLh80ZeNeFpoKzwV Hqkj/17g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qWFHI-00EYPy-I7; Wed, 16 Aug 2023 12:05:32 +0000 Date: Wed, 16 Aug 2023 13:05:32 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Andrew Morton , Jens Axboe , io-uring@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 7/9] mm: Add deferred_list page flag Message-ID: References: <20230815032645.1393700-1-willy@infradead.org> <20230815032645.1393700-8-willy@infradead.org> <7c1bb01d-620c-ca97-c4a2-2bb7c126c687@redhat.com> <88bdc3d2-56e4-4c09-77fe-74fb4c116893@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8025C1C0032 X-Stat-Signature: 3zbpq64bpah4g7gctjrqy5qpy176ergx X-Rspam-User: X-HE-Tag: 1692187538-702609 X-HE-Meta: U2FsdGVkX1+uZSBbsQfQeFxwGeRC0gJY5vc9aD4SpBPtB5SMM1q50x/3H4VA3bwOIW3EAJhBJ7QSA1SfI1QDriOCgqHp/W+19bgPBPDhpUiV/1wOuHwPvDtEgGH/HDtZDJH5S7LpihGSekZkvl/UkbXgVqqRifp0FJ6KVvFb9IMcG0U7/rqn66ib3cN6pXxaw0JeVNwEY+2F6KoVCVGJw6AcjVqI+cEP5hWVt503mVQK+kOmb++ujzTtq5tL976DXwjUY842R6DexGqwxfSOgYEe6VwsCjvEFoZPDELbzF5a88plAIqcclwBkXRiQ0Ma92wYqAIETMNPONgwV8n7VJyAxxdkI8kxkerLuCc8qoH+CnArkDxx7e2x1vXaPg2sQ0KxGUIhfK3SSLQupOFvvRdyStwuxOz0hkR7k35k/7xe1PFTTQb2URjTGkI91csNehtbG5fCQ21qzy9+MWYvk2DsEDHWME14ETksfDV69YN6gwmR3btDNTbFFi6mxkTGUbTQWvGW+KSkuZgK1Go83hZPpHg64KSFsvgc9R/Cd0JuYBX6ZHpXVQQdTV4r2Do3G7lb1AICPSZFcRtyleY7kqVk2VH5soGVraxJJIOAa7yskNxnmVz8jFmAoT1v70uhi0zyB2pv7RcXMwa4oS452VkZktLJpoEBuraayU7Q5rveF3g0vtDHKnVo4m+IXbtSiL2lwBuRYjGgmEOHO1S0bVcLjG8n8IcV0Qq4j/MiIH/KSZ47JgTShbkwNc/+qwyhfmAM5PNjHSSMSxP44MZoqYpLgsr+H/VbvEZNsmRYtO1IdpZX6l+HS6Q2083n+IaGk63zqsoqO8ShME/4IkqTwLMY32N8T5gYKRaI++rOYZLla/OFtrA0xRkSFiygXspRIQMux3eSIOuTv8BBai7lAwKpOCGKtARj54udAoOi15NpXJ+4QASpAk3fv69dY2QbeOhJ0RPgOKYStdTnhYU q1c0v+Vw eQfrcBxXfIk/+OD8pJftIIPl6ugRYldH8heNkMYYV6zO9Gdr9t6HoRuAr890jrlTER6gDR6dQdfU96D14xZSV+8/Uh0zqUPYlnoa3pnHgQxNzlFlbNeiyCIY3JdrZ4vUkpdmRskxFjZlf6k15qCiwUQUlweXaf71RtlrWSvL1VF70v27/bmXUrBrYlQpE8XM6Ga2ysrX32IWiCUYiXYypE9TG48AIk4LCGFpz+klGgR3C3qw= 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, Aug 16, 2023 at 12:12:44PM +0200, David Hildenbrand wrote: > On 16.08.23 05:14, Matthew Wilcox wrote: > > > * Are managed on the LRU > > > > I think this is the best one to go with. Either that or "managed by > > rmap". That excludes compoud pages which are allocated from vmalloc() > > (which can be mmaped), page tables, slab, etc. It includes both file > > and anon folios. > > > > I have a handy taxonomy here: https://kernelnewbies.org/MemoryTypes > > > > Unfortunately, folio_test_lru() already exists and means something > > different ("Is this folio on an LRU list"). I fear folio_test_rmap() > > would have a similar confusion -- "Is this folio currently findable by > > rmap", or some such. folio_test_rmappable()? > But what about hugetlb, they are also remappable? We could have > folio_test_rmappable(), but that would then also better include hugetlb ... We could do that! Have both hugetlb & huge_memory.c set the rmappable flag. We'd still know which destructor to call because hugetlb also sets the hugetlb flag. > Starting at the link you provided, I guess "vmalloc" and "net pool" would > not fall under that category, or would they? (I'm assuming they don't get > mapped using the rmap, so they are "different", and they are not managed by > lru). Right, neither type of page ends up on the LRU, and neither is added to rmap. > So I assume we only care about anon+file (lru-managed). Only these are > rmappable (besides hugetlb), correct? > > folio_test_lru_managed() > > Might be cleanest to describe anon+file that are managed by the lru, just > might not be on a lru list right now (difference to folio_test_lru()). Something I didn't think about last night is that this flag only _exists_ for large folios. folio_test_lru_managed() (and folio_test_rmappable()) both sound like they might work if you call them on single-page folios, but we BUG if you do (see folio_flags()) > I've been also thinking about > > "folio_test_normal" > > But it only makes sense when "all others (including hugetlb) are the odd > one". Who's to say slab is abnormal? ;-) But this one also fails to communicate "only call this on large folios". folio_test_splittable() does at least communicate that this is related to large folios, although one might simply expect it to return false for single-page folios rather than BUG. folio_test_large_rmappable()?