Message ID | 20230310103210.22372-5-vbabka@suse.cz |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp793292wrd; Fri, 10 Mar 2023 02:34:45 -0800 (PST) X-Google-Smtp-Source: AK7set+KLoIxIE/NoPg0eYSxhTWSrUJlvxve4TmefaOMQVQQLk2CMHc/3O6L1lhpKbabEn0ZWQYD X-Received: by 2002:aa7:9f85:0:b0:5a8:e9c0:7d0a with SMTP id z5-20020aa79f85000000b005a8e9c07d0amr21269158pfr.4.1678444484828; Fri, 10 Mar 2023 02:34:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678444484; cv=none; d=google.com; s=arc-20160816; b=lqbD1giM4YfH4wzBTYwrKYJg4ymwbY4H1cIQbLLeCn0lL0urJMEbhNXltjJrZD1xhY M+jRqj2BWEAwpyrfZsYd0tcpp8MFlkpJv13HzzWN2fBNih23AFM7ng+FuY5ztI7QC5Ts TkIS7DnAw4i5HWxN29e21KO8tAoIPi2CHzKdbrPKFfAN+qSwDiX1KHN6qO1GCwRMyeOR 6urKNEs9/z2HM1270abvNyNWkqCqQ7USRWIrV89KSxb5mKM5vsNNbyUf1VUCdJ/dvwKm jmNEXo3tVszVc7I0SmsgcRqcZrIQLuMOk016aMpbZ4El2/1IYgeVp2TAJEN66ETQXKyB lUWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=SABMsfykBuZLlX/EID5G4jmWDCswPlY6bB+XmpUmDDI=; b=Rkr78g1B0OBiT7/w32HXhbI/h0U+buBCRcT16hC1Eayks1I4jvACrndms3ixazldWO u/osk6PQC5VhVR8Swe/cGA+JZ189/Bs8hK0B8Nq5nUQOuSo1/OuxeZGvpzG/p9FXyPeq L79cDlyPhQ1k7N0fNzRGs4cndg8woVudBZuz64ttz6/cGJwyHTcDeF3OcKfoUGhe1uaX Ww14JoRYIuUustuPr6GP/349QdDcR6gyH4rz4XCAGlNCGLavfMw94E6Q86J4JHX5hZ1R gYtFahWWRS/H/Rg0QV6i3Hc+taMvHkKu0wq1XkD/GFVcxklLm9P+pZsqzlDPztNeA4ae KeEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=foj1gERE; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t4-20020a632244000000b004fc26d41be6si1656630pgm.72.2023.03.10.02.34.32; Fri, 10 Mar 2023 02:34:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=foj1gERE; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231435AbjCJKcw (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Fri, 10 Mar 2023 05:32:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231192AbjCJKcU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Mar 2023 05:32:20 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B46AA111685; Fri, 10 Mar 2023 02:32:16 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3BDB120655; Fri, 10 Mar 2023 10:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1678444335; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SABMsfykBuZLlX/EID5G4jmWDCswPlY6bB+XmpUmDDI=; b=foj1gEREC5pFoZcss66MTasW9SmKGZ8VO45QQ5RxFr2/gbLbCBrgbYL8TlQQxufdOQ3EFE czVB8jboaSapWQSAvTbgzlr6p+6za4Flui5sC1W23abuExTqIegh6cm1gPfGqBzmxekr0H TCUXtSdOonDGjPPPUlKUoc9FsmC5aAE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1678444335; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SABMsfykBuZLlX/EID5G4jmWDCswPlY6bB+XmpUmDDI=; b=JCOpFCvpQJqkp5/VtYAnLRuXjAB156OkLDECkwvRNK9kuNoHX2iWKKVfw/Gx5/VOde/eYE 9dMcNAa9idgNdMBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 0984B13592; Fri, 10 Mar 2023 10:32:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6Ay0AS8HC2SsXQAAMHmgww (envelope-from <vbabka@suse.cz>); Fri, 10 Mar 2023 10:32:15 +0000 From: Vlastimil Babka <vbabka@suse.cz> To: Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Pekka Enberg <penberg@kernel.org> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin <roman.gushchin@linux.dev>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, rcu@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, netdev@vger.kernel.org, linux-doc@vger.kernel.org, Vlastimil Babka <vbabka@suse.cz> Subject: [PATCH 4/7] mm, pagemap: remove SLOB and SLQB from comments and documentation Date: Fri, 10 Mar 2023 11:32:06 +0100 Message-Id: <20230310103210.22372-5-vbabka@suse.cz> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230310103210.22372-1-vbabka@suse.cz> References: <20230310103210.22372-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759976604032282813?= X-GMAIL-MSGID: =?utf-8?q?1759976604032282813?= |
Series |
remove SLOB and allow kfree() with kmem_cache_alloc()
|
|
Commit Message
Vlastimil Babka
March 10, 2023, 10:32 a.m. UTC
SLOB has been removed and SLQB never merged, so remove their mentions
from comments and documentation of pagemap.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Documentation/admin-guide/mm/pagemap.rst | 6 +++---
fs/proc/page.c | 5 ++---
2 files changed, 5 insertions(+), 6 deletions(-)
Comments
On Fri, Mar 10, 2023 at 11:32:06AM +0100, Vlastimil Babka wrote: > SLOB has been removed and SLQB never merged, so remove their mentions > from comments and documentation of pagemap. > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > --- > Documentation/admin-guide/mm/pagemap.rst | 6 +++--- > fs/proc/page.c | 5 ++--- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst > index b5f970dc91e7..bb4aa897a773 100644 > --- a/Documentation/admin-guide/mm/pagemap.rst > +++ b/Documentation/admin-guide/mm/pagemap.rst > @@ -91,9 +91,9 @@ Short descriptions to the page flags > The page is being locked for exclusive access, e.g. by undergoing read/write > IO. > 7 - SLAB > - The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. > - When compound page is used, SLUB/SLQB will only set this flag on the head > - page; SLOB will not flag it at all. > + The page is managed by the SLAB/SLUB kernel memory allocator. > + When compound page is used, either will only set this flag on the head > + page.. > 10 - BUDDY > A free memory block managed by the buddy system allocator. > The buddy system organizes free memory in blocks of various orders. > diff --git a/fs/proc/page.c b/fs/proc/page.c > index 6249c347809a..1356aeffd8dc 100644 > --- a/fs/proc/page.c > +++ b/fs/proc/page.c > @@ -125,7 +125,7 @@ u64 stable_page_flags(struct page *page) > /* > * pseudo flags for the well known (anonymous) memory mapped pages > * > - * Note that page->_mapcount is overloaded in SLOB/SLUB/SLQB, so the > + * Note that page->_mapcount is overloaded in SLAB/SLUB, so the SLUB does not overload _mapcount. > * simple test in page_mapped() is not enough. > */ > if (!PageSlab(page) && page_mapped(page)) > @@ -166,8 +166,7 @@ u64 stable_page_flags(struct page *page) > > /* > * Caveats on high order pages: page->_refcount will only be set > - * -1 on the head page; SLUB/SLQB do the same for PG_slab; > - * SLOB won't set PG_slab at all on compound pages. > + * -1 on the head page; SLAB/SLUB do the same for PG_slab; I think this comment could be just saying that PG_buddy is only set on head page, not saying _refcount is set to -1 on head page (is it even correct?) > */ > if (PageBuddy(page)) > u |= 1 << KPF_BUDDY; > -- > 2.39.2 >
On Fri, Mar 10, 2023 at 11:32:06AM +0100, Vlastimil Babka wrote: > SLOB has been removed and SLQB never merged, so remove their mentions > from comments and documentation of pagemap. > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > --- > Documentation/admin-guide/mm/pagemap.rst | 6 +++--- > fs/proc/page.c | 5 ++--- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst > index b5f970dc91e7..bb4aa897a773 100644 > --- a/Documentation/admin-guide/mm/pagemap.rst > +++ b/Documentation/admin-guide/mm/pagemap.rst > @@ -91,9 +91,9 @@ Short descriptions to the page flags > The page is being locked for exclusive access, e.g. by undergoing read/write > IO. > 7 - SLAB > - The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. > - When compound page is used, SLUB/SLQB will only set this flag on the head > - page; SLOB will not flag it at all. > + The page is managed by the SLAB/SLUB kernel memory allocator. > + When compound page is used, either will only set this flag on the head > + page.. I mean, perhaps the nittiest of nits but probably that '..' is unintended. > 10 - BUDDY > A free memory block managed by the buddy system allocator. > The buddy system organizes free memory in blocks of various orders. > diff --git a/fs/proc/page.c b/fs/proc/page.c > index 6249c347809a..1356aeffd8dc 100644 > --- a/fs/proc/page.c > +++ b/fs/proc/page.c > @@ -125,7 +125,7 @@ u64 stable_page_flags(struct page *page) > /* > * pseudo flags for the well known (anonymous) memory mapped pages > * > - * Note that page->_mapcount is overloaded in SLOB/SLUB/SLQB, so the > + * Note that page->_mapcount is overloaded in SLAB/SLUB, so the > * simple test in page_mapped() is not enough. > */ > if (!PageSlab(page) && page_mapped(page)) > @@ -166,8 +166,7 @@ u64 stable_page_flags(struct page *page) > > /* > * Caveats on high order pages: page->_refcount will only be set > - * -1 on the head page; SLUB/SLQB do the same for PG_slab; > - * SLOB won't set PG_slab at all on compound pages. > + * -1 on the head page; SLAB/SLUB do the same for PG_slab; Nice catch on the redundant reference to the mysterous SLQB (+ above) :) > */ > if (PageBuddy(page)) > u |= 1 << KPF_BUDDY; > -- > 2.39.2 > Otherwise looks good to me, Acked-by: Lorenzo Stoakes <lstoakes@gmail.com>
On 3/14/23 09:19, Hyeonggon Yoo wrote: > On Fri, Mar 10, 2023 at 11:32:06AM +0100, Vlastimil Babka wrote: >> SLOB has been removed and SLQB never merged, so remove their mentions >> from comments and documentation of pagemap. >> >> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >> --- >> Documentation/admin-guide/mm/pagemap.rst | 6 +++--- >> fs/proc/page.c | 5 ++--- >> 2 files changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst >> index b5f970dc91e7..bb4aa897a773 100644 >> --- a/Documentation/admin-guide/mm/pagemap.rst >> +++ b/Documentation/admin-guide/mm/pagemap.rst >> @@ -91,9 +91,9 @@ Short descriptions to the page flags >> The page is being locked for exclusive access, e.g. by undergoing read/write >> IO. >> 7 - SLAB >> - The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. >> - When compound page is used, SLUB/SLQB will only set this flag on the head >> - page; SLOB will not flag it at all. >> + The page is managed by the SLAB/SLUB kernel memory allocator. >> + When compound page is used, either will only set this flag on the head >> + page.. >> 10 - BUDDY >> A free memory block managed by the buddy system allocator. >> The buddy system organizes free memory in blocks of various orders. >> diff --git a/fs/proc/page.c b/fs/proc/page.c >> index 6249c347809a..1356aeffd8dc 100644 >> --- a/fs/proc/page.c >> +++ b/fs/proc/page.c >> @@ -125,7 +125,7 @@ u64 stable_page_flags(struct page *page) >> /* >> * pseudo flags for the well known (anonymous) memory mapped pages >> * >> - * Note that page->_mapcount is overloaded in SLOB/SLUB/SLQB, so the >> + * Note that page->_mapcount is overloaded in SLAB/SLUB, so the > > SLUB does not overload _mapcount. True, I overlooked that, thanks. >> * simple test in page_mapped() is not enough. >> */ >> if (!PageSlab(page) && page_mapped(page)) >> @@ -166,8 +166,7 @@ u64 stable_page_flags(struct page *page) >> >> /* >> * Caveats on high order pages: page->_refcount will only be set >> - * -1 on the head page; SLUB/SLQB do the same for PG_slab; >> - * SLOB won't set PG_slab at all on compound pages. >> + * -1 on the head page; SLAB/SLUB do the same for PG_slab; > > I think this comment could be just saying that PG_buddy is only set on > head page, not saying > > _refcount is set to -1 on head page (is it even correct?) It's not, that scheme is outdated. So I'll have it mention PG_buddy as you suggest, but PG_slab also needs special care as it's not set on tail pages. But I noticed the compound_head() is unnecessary as that's covered by PageSlab() which is defined as PF_NO_TAIL. So the sum of modifications to this patch: diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index bb4aa897a773..c8f380271cad 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -93,7 +93,7 @@ Short descriptions to the page flags 7 - SLAB The page is managed by the SLAB/SLUB kernel memory allocator. When compound page is used, either will only set this flag on the head - page.. + page. 10 - BUDDY A free memory block managed by the buddy system allocator. The buddy system organizes free memory in blocks of various orders. diff --git a/fs/proc/page.c b/fs/proc/page.c index 1356aeffd8dc..195b077c0fac 100644 --- a/fs/proc/page.c +++ b/fs/proc/page.c @@ -125,7 +125,7 @@ u64 stable_page_flags(struct page *page) /* * pseudo flags for the well known (anonymous) memory mapped pages * - * Note that page->_mapcount is overloaded in SLAB/SLUB, so the + * Note that page->_mapcount is overloaded in SLAB, so the * simple test in page_mapped() is not enough. */ if (!PageSlab(page) && page_mapped(page)) @@ -165,8 +165,8 @@ u64 stable_page_flags(struct page *page) /* - * Caveats on high order pages: page->_refcount will only be set - * -1 on the head page; SLAB/SLUB do the same for PG_slab; + * Caveats on high order pages: PG_buddy and PG_slab will only be set + * on the head page. */ if (PageBuddy(page)) u |= 1 << KPF_BUDDY; @@ -184,7 +184,7 @@ u64 stable_page_flags(struct page *page) u |= kpf_copy_bit(k, KPF_LOCKED, PG_locked); u |= kpf_copy_bit(k, KPF_SLAB, PG_slab); - if (PageTail(page) && PageSlab(compound_head(page))) + if (PageTail(page) && PageSlab(page)) u |= 1 << KPF_SLAB; u |= kpf_copy_bit(k, KPF_ERROR, PG_error);
diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index b5f970dc91e7..bb4aa897a773 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -91,9 +91,9 @@ Short descriptions to the page flags The page is being locked for exclusive access, e.g. by undergoing read/write IO. 7 - SLAB - The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. - When compound page is used, SLUB/SLQB will only set this flag on the head - page; SLOB will not flag it at all. + The page is managed by the SLAB/SLUB kernel memory allocator. + When compound page is used, either will only set this flag on the head + page.. 10 - BUDDY A free memory block managed by the buddy system allocator. The buddy system organizes free memory in blocks of various orders. diff --git a/fs/proc/page.c b/fs/proc/page.c index 6249c347809a..1356aeffd8dc 100644 --- a/fs/proc/page.c +++ b/fs/proc/page.c @@ -125,7 +125,7 @@ u64 stable_page_flags(struct page *page) /* * pseudo flags for the well known (anonymous) memory mapped pages * - * Note that page->_mapcount is overloaded in SLOB/SLUB/SLQB, so the + * Note that page->_mapcount is overloaded in SLAB/SLUB, so the * simple test in page_mapped() is not enough. */ if (!PageSlab(page) && page_mapped(page)) @@ -166,8 +166,7 @@ u64 stable_page_flags(struct page *page) /* * Caveats on high order pages: page->_refcount will only be set - * -1 on the head page; SLUB/SLQB do the same for PG_slab; - * SLOB won't set PG_slab at all on compound pages. + * -1 on the head page; SLAB/SLUB do the same for PG_slab; */ if (PageBuddy(page)) u |= 1 << KPF_BUDDY;