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 5017BC433EF for ; Wed, 23 Feb 2022 03:45:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9023E8D0002; Tue, 22 Feb 2022 22:45:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B1498D0001; Tue, 22 Feb 2022 22:45:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 751CA8D0002; Tue, 22 Feb 2022 22:45:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id 63C488D0001 for ; Tue, 22 Feb 2022 22:45:33 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1C7FC98C04 for ; Wed, 23 Feb 2022 03:45:33 +0000 (UTC) X-FDA: 79172654946.24.4917F86 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf10.hostedemail.com (Postfix) with ESMTP id A32DAC0002 for ; Wed, 23 Feb 2022 03:45:32 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id l8so17496220pls.7 for ; Tue, 22 Feb 2022 19:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=POgOhfAItwuaPNB2w+jcz1CIKtfz6HfnT0NLLHUTB/Q=; b=QIUpkEH5J8BZGJX0HW2/3D8Lpcsf5+9OOGgwxy3FAe8G60lrbOK8anmPbOCtZ2SStM WuJvKRpLdJiMPCqaFbGUhCwAVLPmA8daG/VdwQX1BPgOHq6lufumaYtjyf6gFWY7p3h8 HYcr9N5ZStmNjfUi/yIiW9JB1FUvKd63Rg8NIDM3h0Chfqd1h+YCiC20CBsbJtpWp39v LTSg78xpWmTl5wNANhiu0tELz1h7bLLVn6sp9LAMo5leXW3fBwoHhN/WNZzmLZbPiIQG fG9e3yIukNfZOFI+NIVCslzkK/BTqNKsu289bD2IsTVZbgg2w8fUlRVL3XhmmOKa+PI5 lbAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=POgOhfAItwuaPNB2w+jcz1CIKtfz6HfnT0NLLHUTB/Q=; b=duYVQ5J7cokBgPkfzJASws8LZJemKK4/xhV6awTeC2VXGlgvpezPrmnDl4dQc12vJv 1bkdN7nHVGO3fRROqiu3IsDy2dfP2iEQYJjmu0xwgOfaPRFv1WORO4pZ073MPXPISVar KdNkROT37xl5eW4i6BVBdCwsArKoCNF0R8v9326RVFLvb1iTjb4M9gXzjTUrY3FpTfbe PElvU/LDrhbApeZ9CsFiGBlmJ4GS12tpuGJtwe8tv53sKV4xvORX0dj+r3+lHOFkMeVF Yja6PF1UcpAhhpNe0kBYGX34Bl1nsj6VPjklxwE5JcNxp6F4oVZixtQRfaoG0NqrQYBx oQpg== X-Gm-Message-State: AOAM530GLWdRNLExeJnEP1X13hDVNNIxDtYMy+Wk0Z81ZFQ15LMxpyiT g/LIDca4OfL4g6FnGPO2+6g= X-Google-Smtp-Source: ABdhPJzlB79g1xEsNcmhdWPAN+T4P0RSf+r7hFxiRSScMMQCu25Vh4o6ddaGPxzxclrT7JbtBpEENw== X-Received: by 2002:a17:902:a381:b0:14f:53a7:f340 with SMTP id x1-20020a170902a38100b0014f53a7f340mr25653183pla.158.1645587931709; Tue, 22 Feb 2022 19:45:31 -0800 (PST) Received: from ip-172-31-19-208.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id z15sm18434440pfh.82.2022.02.22.19.45.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Feb 2022 19:45:31 -0800 (PST) Date: Wed, 23 Feb 2022 03:45:26 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: Roman Gushchin , Vasily Averin , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , Linux MM , Andrew Morton , kernel@openvz.org Subject: Re: slabinfo shows incorrect active_objs ??? Message-ID: References: <5f318050-cf2a-2e3b-b980-f449d5c54f7c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A32DAC0002 X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QIUpkEH5; spf=pass (imf10.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: xtpnq7q335xo1jd569f68b4nq839tw1h X-HE-Tag: 1645587932-389649 Content-Transfer-Encoding: quoted-printable 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 Wed, Feb 23, 2022 at 01:32:36AM +0100, Vlastimil Babka wrote: > On 2/23/22 01:07, Roman Gushchin wrote: > >=20 > >> On Feb 22, 2022, at 3:08 PM, Vlastimil Babka wrote: > >>=20 > >> =EF=BB=BFOn 2/22/22 21:59, Roman Gushchin wrote: > >>>=20 > >>>> On Feb 22, 2022, at 4:10 AM, Vasily Averin wro= te: > >>=20 > >> BTW please To/Cc directly all slab maintainers on future slab relate= d > >> threads (added now). > >>=20 > >>>> =EF=BB=BFOn 22.02.2022 13:23, Hyeonggon Yoo wrote: > >>>>>>> On Tue, Feb 22, 2022 at 12:22:02PM +0300, Vasily Averin wrote: > >>>>>>> Dear all, > >>>>>>>=20 > >>>>>>> I've found that /proc/slabinfo shows inadequate numbers of in-u= se slab objects. > >>>>>>> it assumes that all objects stored in cpu caches are always 100= % in use. > >>>>=20 > >>>>>> Is it a bug or perhaps a well-known feature that I missed? > >>>>> This is not a bug.. > >>>>=20 > >>>> Thank you for explanation, > >>>> I think it would be useful to document this somewhere. (Documnetat= ion? man slabinfo ?) > >>>> Also I would like to know is it some (fast) way to get real number= s in userspace ? > >>>> crash is too fat for this task. > >>>> Do you know perhaps some other userspace utility or may be systemt= ap/drgn script? > >>>=20 > >>> Btw, implementing fast slab counters independent from the sl*b impl= ementation and the physical layout of data might be an interesting idea. > >>=20 > >> Interesting idea, but merging will be an issue if we ever manage to > >> officially allow kfree() on object allocated by kmem_cache_alloc() -= which > >> is now blocked by SLOB (there was a recent thread that stalled). > >=20 > > Well, we can store an id somewhere (like right behind the object). > > Depending on the object size and padding it might even take not so mu= ch > > extra space. Maybe not the feature everybody needs (so it can be turn= ed > > off by default), but something that can be really useful in some case= s. > 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 = with > static keys) anyway so those who don't need them can avoid the overhead= . 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()... Or would you count them by iterating all of cpu partial slabs and node partial slabs? (Something like drgn script or new procfs file?) --=20 Hyeonggon