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 BD9C5C433F5 for ; Fri, 25 Feb 2022 00:09:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CDA28D0002; Thu, 24 Feb 2022 19:09:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07CFD8D0001; Thu, 24 Feb 2022 19:09:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAD538D0002; Thu, 24 Feb 2022 19:09:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id D8B9C8D0001 for ; Thu, 24 Feb 2022 19:09:00 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 81B869F846 for ; Fri, 25 Feb 2022 00:09:00 +0000 (UTC) X-FDA: 79179366840.31.E9ABFB7 Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by imf30.hostedemail.com (Postfix) with ESMTP id 7332E8000C for ; Fri, 25 Feb 2022 00:08:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1645747737; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JykR8TEDc39FAdk4VlD7hK0h5mdBA5vQfq//0FQj3pM=; b=Aoj4kZO0lnprribLbbrayqbMYmQUV2tuYD8VVs/blL8vkjhObvZP5+S/ed4oJYK8MqBodu efkrLMeVoKUy/51ihFtNy/1qUdbssYOTsactGEwNnOnhPQ6Mm4+C62LAbBDMdT8SmQflfN UIa70c6pKdCgp5DYIiZmX8jr8ahRe5Q= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: slabinfo shows incorrect active_objs ??? X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin In-Reply-To: Date: Thu, 24 Feb 2022 16:08:54 -0800 Cc: Vlastimil Babka , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , Linux MM , Andrew Morton , kernel@openvz.org Message-Id: <4BC89091-F314-4785-BCBB-189CE42B0192@linux.dev> References: To: Vasily Averin X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7332E8000C X-Stat-Signature: 6y8p5wx43wkxurc3gmz6fahjeunywysd Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Aoj4kZO0; spf=pass (imf30.hostedemail.com: domain of roman.gushchin@linux.dev designates 94.23.1.103 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Rspam-User: X-HE-Tag: 1645747739-135176 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 Feb 24, 2022, at 5:17 AM, Vasily Averin wrote: >=20 > =EF=BB=BFOn 22.02.2022 19:32, Shakeel Butt wrote: >> If you are just interested in the stats, you can use SLAB for your experi= ments. >=20 > Unfortunately memcg_slabino.py does not support SLAB right now. >=20 >> On 23.02.2022 20:31, Vlastimil Babka wrote: >>> On 2/23/22 04:45, Hyeonggon Yoo wrote: >>> On Wed, Feb 23, 2022 at 01:32:36AM +0100, Vlastimil Babka wrote: >>>> Hm it would be easier just to disable merging when the precise counters= are >>>> enabled. Assume it would be a config option (possibly boot-time option w= ith >>>> static keys) anyway so those who don't need them can avoid the overhead= . >>>=20 >>> Is it possible to accurately account objects in SLUB? I think it's not >>> easy because a CPU can free objects to remote cpu's partial slabs using >>> cmpxchg_double()... >> AFAIU Roman's idea would be that each alloc/free would simply inc/dec an >> object counter that's disconnected from physical handling of particular s= l*b >> implementation. It would provide exact count of objects from the perspect= ive >> of slab users. >> I assume for reduced overhead the counters would be implemented in a perc= pu >> fashion as e.g. vmstats. Slabinfo gathering would thus have to e.g. sum u= p >> those percpu counters. >=20 > I like this idea too and I'm going to spend some time for its implementati= on. Sounds good! Unfortunately it=E2=80=99s quite tricky: the problem is that there is potent= ially a large and dynamic set of cgroups and also large and dynamic set of s= lab caches. Given the performance considerations, it=E2=80=99s also unlikely= to avoid using percpu variables. So we come to the (nr_slab_caches * nr_cgroups * nr_cpus) number of =E2=80=9C= objects=E2=80=9D. If we create them proactively, we=E2=80=99re likely wastin= g lot of memory. Creating them on demand is tricky too (especially without l= osing some accounting accuracy). Thanks!=