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 6B9FBC54E5D for ; Thu, 14 Mar 2024 23:45:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58463800EA; Thu, 14 Mar 2024 19:45:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 535D1800B4; Thu, 14 Mar 2024 19:45:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D583800EA; Thu, 14 Mar 2024 19:45:08 -0400 (EDT) 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 2C88C800B4 for ; Thu, 14 Mar 2024 19:45:08 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B6A80A12BE for ; Thu, 14 Mar 2024 23:45:07 +0000 (UTC) X-FDA: 81897277854.02.6FAFD06 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf08.hostedemail.com (Postfix) with ESMTP id 2951716000F for ; Thu, 14 Mar 2024 23:45:05 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf08.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=1710459906; a=rsa-sha256; cv=none; b=oFJWkxHxxsrZGN7R11cdQvrciB+QuAbCLGKnoX6TI76mrnAe0AGdHgGeH+kkooIIrniFnn NPpz73c5gOjJFT+EL/n/xRZo0YJjJVCszCn5nAJMcWHqBdiq/nzhbfDw93X19sHsTEMUwP eIoY+eL0pg3WCJg49sQWXxSAhaWmOxA= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf08.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=1710459906; 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=XEe4N+8+OgMq+b0cHgfraz9GRo/xdoucXnl3gK3KZLo=; b=K04HCh8izb+7+bPM6ydHRqwPp9TENH+2kU15xEd53A2otgwZ61Y92Wy//VshG1RmG8ysI/ R7mdGtlcmtmCD5m5/HwR3L5HvPbDKB6Y2aFEpznfAiQHXleGN1nyRRm/lHzGWnfouS1g5p PwdngfsBUKCEy38SG9DDtx0guJwA6gU= Received: by gentwo.org (Postfix, from userid 1003) id B71BC40AB2; Thu, 14 Mar 2024 16:45:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id B4C8340A8D; Thu, 14 Mar 2024 16:45:04 -0700 (PDT) Date: Thu, 14 Mar 2024 16:45:04 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Jianfeng Wang cc: Vlastimil Babka , Chengming Zhou , David Rientjes , 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 Subject: Re: [PATCH] slub: avoid scanning all partial slabs in get_slabinfo() In-Reply-To: <9578474c-2e46-4d3e-9a2f-1eaeb9bfabbc@oracle.com> Message-ID: <1e01092b-140d-2bab-aeba-321a74a194ee@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> <1eeb84d4-42b1-d204-ece1-b76bfbc548bf@linux.com> <0aa3ce20-438f-49fb-8f04-4fc1dbf49728@linux.dev> <9578474c-2e46-4d3e-9a2f-1eaeb9bfabbc@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2951716000F X-Stat-Signature: a136ubd7rmuyepuktzd1ner51bo7pm9y X-Rspam-User: X-HE-Tag: 1710459905-895641 X-HE-Meta: U2FsdGVkX1/YCdqR9fvyqTckY5cpMj9UCjdDAego1TOx/EZtgQcd104p6Ihkto2Dz1oGGIfS27d6ZfYMpTLpWa6DTbri9ngwX8Z1GFht7KLKDmun93myQfDg0JCiFBh3mXkpu+N3rejwB8s2gV8GyllQpNaLYA9uZ//5YTe9q9pLghiTowvseXtd93hL1zTxqdoN9an6U+atwGWqehqKqFG3GtbhAl8vUlXeNjnAHLuQC1PU+B2CGPqn+lUERibhLOHojWQxS7lGQtL0V65H5uUYV190UCQv582c/IB7f7mH2YJ75hfgLUleTYpLNWjLTx9J7yblbOwpFwln24i3EbjTzINpzYd7ry0WEhB83VDj3vRuFuqT2obJbF25uFhPMPaWMS6hVCyb3iSdCYoG1zS/jmR1EHLlk1ag/LGv4fPc86UM+CDs51EB6N2BMku2PHkarxKpRcbPSrBWZQev1stKhjpNyOcq37lqdV6EfQ36RuPc2qGei0toY1UyGVXK6Vf73ioOsGYDDk4/OBqOHpp2Ujd+DoeYoKFiNZduZKQBC4qgv+uQ2hWAgNIPO4WdyCf+hEDpiGNyK8bCTQFrXKX+ekfgGWyGaFl0TMLSGKzqvwKltA0jvGEkF+ANl8Z1tMl+kQxruGyU2JssiYhGwNKpOhZ0QseUWNEM6XAioFKERrozI0AJkdGkEopv+sySem+1J0QcqEgMcQdl+1NE9MIUGipNDRHzxFS5GqnVoGsC16A9jpqqe0JaTb1ci+Y7NLIP2MLDwplb6sBSlvGorNDAtIIp8J0cTA3A4wI7jqTNmuNTT65wg5XrTu2NU6b572rMooOFsLX5PZ36xLAbQ7c2FFcThhOuXr21cRUt6rv1yzS4ZVETtN5Ff93dhv74nR7OdzzAZBNPbU8uQp4MdTFqsyPJZVXw 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: On Wed, 13 Mar 2024, Jianfeng Wang wrote: > I am not sure that the RCU change will solve the lockup problem. > The reason is that iterating a super long list of partial slabs is a problem by itself, e.g., on a > non-preemptive kernel, then count_partial() can be stuck in the loop for a while, which can cause problems. > > Also, even if we check the list ownership for slabs, we may spend too much time in the loop if no updater shows up, > or fail and re-do many times the loop if several updates happen. The latter can exacerbate this lockup issue. So, > in the end, reading /proc/slabinfo can take a super long time just for a counter that may be changing all the time. Well we could also cache the values somehow to avoid the scans? invalidate the counter if something significant happens. > Thus, I prefer the "guesstimate" approach, even if the number is inaccurate or biased. Let me know if this makes sense. Come up with a patch and then lets see how well it works.