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 626ABC54798 for ; Tue, 27 Feb 2024 22:55:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A833B6B0249; Tue, 27 Feb 2024 17:55:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A33856B024A; Tue, 27 Feb 2024 17:55:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FB5E6B024B; Tue, 27 Feb 2024 17:55:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 79ACA6B0249 for ; Tue, 27 Feb 2024 17:55:18 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4D61080DA4 for ; Tue, 27 Feb 2024 22:55:18 +0000 (UTC) X-FDA: 81839091516.28.1D17DFD Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf28.hostedemail.com (Postfix) with ESMTP id B9CC5C0018 for ; Tue, 27 Feb 2024 22:55:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf28.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709074517; 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; bh=Khf3NkS+x9fCYAZtpJKeUC1pvc+BVOLRy6VrNdIRkPk=; b=YKTbnbMan1HEmyeXlnJ0Y90n+nX5+tlXkgbR6X+btBS/6Ths9tk7u7Y92Ht1cSAmycI3uy 1jIZKLR+p7oXfS7p1OqR5eYNtm82J6GpmBBFTkrHvkFe43tPymYi5fXkLdg/nxPLzGd8Pq G7dr7R4Co95nn4tFzSTbYVJUH4vfplk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf28.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709074517; a=rsa-sha256; cv=none; b=fEEmyewEDmVOaWFKQTjct8/pgnQfAzH+Iv1v+Ub1XiNoLCC2c6XChd069t5pHA242/zTYY P44GnJZhhVpMZbuDsmKmFL/Au2aBT3dNov+FfM+OzaR+kpb/B1qeWJcg6tq1yywLHuOMGc JtjjZtMHGIO677V2SlaSmSSsLWCtkEA= Received: by gentwo.org (Postfix, from userid 1003) id 7110540AB1; Tue, 27 Feb 2024 14:55:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 7052F40941; Tue, 27 Feb 2024 14:55:15 -0800 (PST) Date: Tue, 27 Feb 2024 14:55:15 -0800 (PST) From: "Christoph Lameter (Ampere)" To: Chengming Zhou cc: Vlastimil Babka , David Rientjes , Jianfeng Wang , penberg@kernel.org, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chengming Zhou Subject: Re: [PATCH] slub: avoid scanning all partial slabs in get_slabinfo() In-Reply-To: Message-ID: <1eeb84d4-42b1-d204-ece1-b76bfbc548bf@linux.com> References: <20240215211457.32172-1-jianfeng.w.wang@oracle.com> <6b58d81f-8e8f-3732-a5d4-40eece75013b@google.com> <55ccc92a-79fa-42d2-97d8-b514cf00823b@linux.dev> <6daf88a2-84c2-5ba4-853c-c38cca4a03cb@linux.com> <347b870e-a7d5-45df-84ba-4eee37b74ff6@linux.dev> <1a952209-fa22-4439-af27-bf102c7d742b@suse.cz> <2744dd57-e76e-4d80-851a-02898f87f9be@suse.cz> <036f2bb4-b086-2988-e46d-86d399405687@linux.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-782571119-1709074515=:1258276" X-Rspamd-Queue-Id: B9CC5C0018 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ahrgnk8b5wy74cuzo9hsoehy6p7wsnc3 X-HE-Tag: 1709074516-568168 X-HE-Meta: U2FsdGVkX19GGvpxzco8Bxp9XY21GOHYbEhzXOpsUFO9qH8qQDbFS4XtZG1C7Gic9FYL9rQ3LSx541//JQcWyDLxpxHgp9HOIAhC9rxYRXleTsKFuqsMjftZeVKLPmRKuuLTmnxIxqAOvlF/4+h3uukUbA/Y9sj8PkisnFDILO/xgVav90GhfyZn7oRk/Y7qz5ew6hgWNpOrE/EgbnSshrSKjihXW1LU2RLm9IyDEXzLPkPJOizSd2MpMK6EG1jsqMTRiocgeHx5KilC4/HE2avMQItemShIqSz+bpC/r0DngWe7pz9i9ANdjoGIwKD+kJMW0X5A8TXaaKKa5v/QZKTWHcjilsgdqgi7FzFMG+Lj1+mjKNgnW+GC+Q8Y/IACEIUShF0gf6I4c/gUSzRXjUbzkcW1NgotY0nGvLQQq6+IcP/hBJn1xDe/CKdUzSlnRQYeyHdA9xJ1lZTLIP63shCS+lc1iJbGEYhjNYt9n8xzlqqkcaw1UDm6Ost08pNEWLeB8sZKIg4AipMizjUDu9dBzV4pseXKoDndGDX2Cn3t2vhaNIsd5x6beV93QWy/0AZCdsmqOjemb01dmVJD6dDJleCpmgy7WFk2Dwg17UMRC5I3Mg8nSedgTz0ZE6n7cZf2NtszJATU9AMwjpkChvAU5tLHESphyW5a1W5Oa/hUdM9hYgHD50ajyiNui1LkNQnzRTYJ8m2JNIRQWAqOPBmPdgQFO0l0UCK15Bd5fSJOiUK8A+VeruAArk9hfRnFuzFYMYryS4KLuowpdiJInUC6L4lAKHKFmfMNGx4vaW7L9ZyBYctLJnipEU26xSvrC4+4aoM9RkgVN6Bib+5aqEWzjN770P512IDtsDE8Q6KSJje1drYynFvsbuU4NCmEC+jRmFtdDJBBnQnd5K4288FWMxPMjy3GMb9KN4PB62CPqCumWtxUjjAzwZnQK7Z+bzLHOkg/95OPB0q/9vr XbOANHyH 3OwxsN2tENNZiwAwwUg0ai05lAn/HXkJiu4XfC+cjIoCldiA= 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: List-Subscribe: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-782571119-1709074515=:1258276 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 27 Feb 2024, Chengming Zhou wrote: >> We could mark the state change (list ownership) in the slab metadata and then abort the scan if the state mismatches the list. > > It seems feasible, maybe something like below? > > But this way needs all kmem_caches have SLAB_TYPESAFE_BY_RCU, right? No. If a slab is freed to the page allocator and the fields are reused in a different way then we would have to wait till the end of the RCU period. This could be done with a deferred free. Otherwise we have the type checking to ensure that nothing untoward happens in the RCU period. The usually shuffle of the pages between freelists/cpulists/cpuslab and fully used slabs would not require that. > Not sure if this is acceptable? Which may cause random delay of memory free. > > ``` > retry: > rcu_read_lock(); > > h = rcu_dereference(list_next_rcu(&n->partial)); > > while (h != &n->partial) { Hmm... a linked list that forms a circle? Linked lists usually terminate in a NULL pointer. So this would be redo: rcu_read_lock(); h = ; while (h && h->type == ) { /* Maybe check h->type again */ if (h->type != ) break; h = ; } rcu_read_unlock(); if (!h) /* Type of list changed under us */ goto redo; The check for type == is racy. Maybe we can ignore that or we could do something additional. Using RCU does not make sense if you add locking in the inner loop. Then it gets too complicated and causes delay. This must be a simple fast lockless loop in order to do what we need. Presumably the type and list pointers are in the same cacheline and thus could made to be updated in a coherent way if properly sequenced with fences etc. --8323329-782571119-1709074515=:1258276--