From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gentwo.org (gentwo.org [62.72.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D68A91079D for ; Thu, 14 Mar 2024 23:45:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.72.0.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710459909; cv=none; b=YhvrmaT7KNcwuXLj+8eUAKBNgwwU+qcv2LmN/Bl5xUQYFrt/RZjdMS4S4OhJktNm48a1D0sDT3dGL6/Vlhb1zJYFS6voGTXfQeNHDSKMAXhfBPNoDt1z6mTJgsPV3mKqgZr3jHFH6+wd8WbKkUHGgFxS+0gN0jDPZTOcbkrYGus= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710459909; c=relaxed/simple; bh=y6IxvqeK/kUaQYRto7LRl/agj/gFzMwPTYAanWQEbVM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=C7RW3J3nVcLDB68CJOlwuARMqXtqliGvwSoYit+K5gPjctLYoLRbQWjWlSuuFt1BF7sRmInQdHInAnEqM+Da8mUUruRy3cqCITwY+toSxmljjU9R3+es1tJhIKbtq5YBAuum+CGu0NBEmWEoxLfpc3RlH/kuUqD7tn8G8dixeXA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.com; spf=fail smtp.mailfrom=linux.com; arc=none smtp.client-ip=62.72.0.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=linux.com 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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.