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 91CD0C7115D for ; Thu, 29 Aug 2024 02:36:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E224F6B00D5; Wed, 28 Aug 2024 22:36:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD1246B00D6; Wed, 28 Aug 2024 22:36:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C717C6B00D7; Wed, 28 Aug 2024 22:36:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A55316B00D5 for ; Wed, 28 Aug 2024 22:36:49 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 583B6A096F for ; Thu, 29 Aug 2024 02:36:49 +0000 (UTC) X-FDA: 82503720138.07.9A83026 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) by imf26.hostedemail.com (Postfix) with ESMTP id 64C6D140007 for ; Thu, 29 Aug 2024 02:36:47 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vsqOzIQO; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.185 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724898987; a=rsa-sha256; cv=none; b=t9kDJ42aiGP3qHU+34WyLCtOQgmK1KY5FzRr+rFjjnEnrWl2ClD1Ymg1bVtKOk+pXPBroq ze97O/Xo5qJGEHi4yI+wYwiVOeHSO9qMPAgPVUEWZsQUHJHV4ie0E9GbzrvNBsbFiLTjVV NPxKV4Tm9hWgKS6vqs5es5o+IXgMAdw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vsqOzIQO; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.185 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724898987; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bGlQAlKtPj4qnjGq3CAst/qDUBkSaSOOIVGCqBBJ/L4=; b=zP8QRZEw6pCkB4PnXUa3O+sicwBO23mYSwsztZywNgdTMxen2E+3y0Ogu+PXzz9We+M2Wr cw+x0iyVk9EUac4pg894xpkS6yKX56BZoG9TFUQUFn9FnV2iQgEQmIJk3PpU83+4H3Yd10 WDxQGjNXGhbUJKRmnkedPzHqagy3HW4= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724899005; 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=bGlQAlKtPj4qnjGq3CAst/qDUBkSaSOOIVGCqBBJ/L4=; b=vsqOzIQOPmUD/dI//siE4+IIQngQgXxQBpdpB7E/BzqliMg1RHeAWk5x8XpoV96GvDofCS Y29CW/+TU573wsCN6urLZsB1zRwanhC84C4aE2tiG1Z/svyHG5ZrK7Oyf0Kkzr2vEMAfdm r6jlMDdK5S140QjzXQ26lhat3rHG19o= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: [PATCH v1] memcg: add charging of already allocated slab objects X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Thu, 29 Aug 2024 10:36:01 +0800 Cc: Roman Gushchin , Andrew Morton , Johannes Weiner , Michal Hocko , Vlastimil Babka , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Eric Dumazet , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Linux Memory Management List , LKML , Meta kernel team , cgroups@vger.kernel.org, netdev Content-Transfer-Encoding: quoted-printable Message-Id: <97F404E9-C3C2-4BD2-9539-C40237E71B2B@linux.dev> References: <20240826232908.4076417-1-shakeel.butt@linux.dev> To: Shakeel Butt X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 64C6D140007 X-Rspamd-Server: rspam01 X-Stat-Signature: m3rcg69g961rjrqr85wni7o4urmy1c4z X-HE-Tag: 1724899007-545558 X-HE-Meta: U2FsdGVkX1+FbKO/g/qc7wsmmfxnD0sjCY7L0ujhePGfWIN0xOS1U5tbee4tZuIsspbtjP+C3E8T47dYpmx8wX6GiViuUyVBEAzJmrun7ZJs7i0FSll59n2ZkKVEVespEcjeRfWrsD0ZRMjqK144RrdjtDlvVjfFXD4aGGzQZN8W5+lOdJumB+mPs/sfEHh2EfWsPH7Fghnw4F/HT4ASEmYNzxUNFlXc+v7GEMGjsXh/otlHRh1ePx4d3qhBrjrRao8nFQj5WFuhmvQiM6INdpP8G46r5b7FRbxPih2fMy51kaOg/lSbzS6YPOzPfttDfFk8e6TaBPKsOo1gWVgKDz8Q5l7FoNYP1CTQOqS17CxFo6d+9vLIdU2NIFRkcWEuy3MenD/Qvt1R+fvfnFBoc5JriRZVyKHLy7Zj6IULsjJq4L0wvqH2ZVxwkn2mIYPFOm5DqaGVKj+iIAoi+z00IUOBKipYFDZRCImhgyWBCURvg4OBln7k7CMMIQrzLMCrwod8OgSdUE/WxS1Cnfqd6gIAILfUg9x3acytoYIkzMZdptR3KrxSwoKDkPwar1a+VuEeEXhZ0r/asz+cNcToXJP5HMbm/D0CJ2gOiB9pGFuz+XbiZkL+KL4FyhOPSM0rMo7q+h6HB6AKklnuvHWXYj7Z9eTEJ4IMDg7v8lL3BosqhhSLTCC00/3xAROocJUQizAfGEDnJ9dAw+kg11lhB+uwLXabL5iQ8ukKdl0YdVRr8YtKnCVnCR6F5XaHQ3ByuN/T8/XNgPCtC+dlauQlM4ByIFJ1t7pcHrNQxdlhBW+fD5uBzpDBXLj/XiomAMLKRTGTtuNYrzd8rqB9dZBCUlW6i9kngEQjQ7vRWF/2RdzlgHZfswDSrh+sQWUDHkrKTsHFl2WGJGBYlG6XQwGlPHYecuiePS9Z0MJ9dRrbwCYD70o4JL42PQhC7CFq5I1Yg3I7nH1JW4sdcdgridR aFzYDD9G YHm9103GAx3Hh5GSfnx6x51QiPGEKhBChhUPxS0jFkFsgQj1k4xfgcYVmsnn9w859u9ucuPfYnpuyXWK93+vUd7lQBZ4BVH5cxh4f4fuizgHtsj4yLWDuyzCBCavxSuowjCaScwtfqQmnpxfQpiUudhCTfikUIGVYco5Afm9J6HTUf2ewIygXEG9fsTUZdkEZYYz7ULriCRjuD/KI60PEjuz3+Q== 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 Aug 29, 2024, at 03:03, Shakeel Butt = wrote: >=20 > Hi Muchun, >=20 > On Wed, Aug 28, 2024 at 10:36:06AM GMT, Muchun Song wrote: >>=20 >>=20 >>> On Aug 28, 2024, at 01:23, Shakeel Butt = wrote: >>>=20 > [...] >>>>=20 >>>> Does it handle the case of a too-big-to-be-a-slab-object = allocation? >>>> I think it's better to handle it properly. Also, why return false = here? >>>>=20 >>>=20 >>> Yes I will fix the too-big-to-be-a-slab-object allocations. I = presume I >>> should just follow the kfree() hanlding on !folio_test_slab() i.e. = that >>> the given object is the large or too-big-to-be-a-slab-object. >>=20 >> Hi Shakeel, >>=20 >> If we decide to do this, I suppose you will use = memcg_kmem_charge_page >> to charge big-object. To be consistent, I suggest renaming = kmem_cache_charge >> to memcg_kmem_charge to handle both slab object and big-object. And I = saw >> all the functions related to object charging is moved to memcontrol.c = (e.g. >> __memcg_slab_post_alloc_hook), so maybe we should also do this for >> memcg_kmem_charge? >>=20 >=20 > If I understand you correctly, you are suggesting to handle the = general > kmem charging and slab's large kmalloc (size > KMALLOC_MAX_CACHE_SIZE) > together with memcg_kmem_charge(). However that is not possible due to > slab path updating NR_SLAB_UNRECLAIMABLE_B stats while no updates for > this stat in the general kmem charging path (__memcg_kmem_charge_page = in > page allocation code path). >=20 > Also this general kmem charging path is used by many other users like > vmalloc, kernel stack and thus we can not just plainly stuck updates = to > NR_SLAB_UNRECLAIMABLE_B in that path. Sorry, maybe I am not clear . To make sure we are on the same page, let me clarify my thought. In your v2, I thought if we can rename kmem_cache_charge() to memcg_kmem_charge() since kmem_cache_charge() already has handled both big-slab-object (size > KMALLOC_MAX_CACHE_SIZE) and small-slab-object cases. You know, we have a function of memcg_kmem_charge_page() which could be used for charging = big-slab-object but not small-slab-object. So I thought maybe memcg_kmem_charge() is a good name for it to handle both cases. And if we do this, how about = moving this new function to memcontrol.c since all memcg charging functions are moved to memcontrol.c instead of slub.c. Muchun, Thanks. >=20 > Thanks for taking a look. > Shakeel