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 6D5B8C636F0 for ; Wed, 28 Aug 2024 19:04:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C63D26B0082; Wed, 28 Aug 2024 15:04:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C141F6B0083; Wed, 28 Aug 2024 15:04:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B02776B0085; Wed, 28 Aug 2024 15:04:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 922F56B0082 for ; Wed, 28 Aug 2024 15:04:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2879312079D for ; Wed, 28 Aug 2024 19:04:02 +0000 (UTC) X-FDA: 82502579124.05.7A53CA9 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf14.hostedemail.com (Postfix) with ESMTP id 1AEFB100013 for ; Wed, 28 Aug 2024 19:03:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=K2ALeeyA; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724871820; 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:dkim-signature; bh=j7vkDyir+DMrxX+HGm5Ta48lUpr2OMfmyuMnb1CIktI=; b=fXo1B2BtPHx8ReB1w/4bGkXVxN7qKRzZFl4GMvCQiGnAtnWaL61bG0Y50hieDzZai50llS 2ybssdRJD8ABC2OMNNkPzIwRhcADzVDZ3XlFf6zZ74uLPbNooRKzJotBOlxpB5UcTrJpDF Us2DPUBiytlnZAuDZHxuhFW6S2VeDHU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=K2ALeeyA; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724871820; a=rsa-sha256; cv=none; b=FxWKR4udA5FC8B2fvPO+kfaghuEG7IYo+R0n7QJQTbBAsyXtk6IukR/CNMebFqRgFgBk5X 9LPOCWdph78x7yDEeU3ZAMDpk69cPAbvQJdZKf4JIhN0YxpLQZHTpaADjemM3A6QUBKUU/ yP9ocYu3bG9G/2xqJYW04HIXaBZM6Bw= Date: Wed, 28 Aug 2024 12:03:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724871837; 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: in-reply-to:in-reply-to:references:references; bh=j7vkDyir+DMrxX+HGm5Ta48lUpr2OMfmyuMnb1CIktI=; b=K2ALeeyATuD5JWGchJFR5gsyyuMm7THk7aHTDFHr6e83Ffrdzp/9RjjjjTcyTlbHI4BBrD IzXEqYz3NBwTZ/Qrb0nmDnDELPUQNbI+VqsUl2PRJp1x0AarYG5err9xiLm3VVjdGO54WM U3u/VnwamuC2tX4goM0KqKWdtkQiQN4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Muchun Song 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 Subject: Re: [PATCH v1] memcg: add charging of already allocated slab objects Message-ID: References: <20240826232908.4076417-1-shakeel.butt@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: r91qykxm9n3mi7krxatk8ii1r3do9jdo X-Rspamd-Queue-Id: 1AEFB100013 X-Rspamd-Server: rspam11 X-HE-Tag: 1724871839-670853 X-HE-Meta: U2FsdGVkX1/TpnKTrdVNAYdaor0KRREymxaFzpPDWUJLbOizZlThfBkP/mCAW2PQTIdhvEktLtDh6rDPIMirIw+CqDi1CQoj/dmHtInfCZYhWNNrHUzkD2JXH8f3ToRaiGUdpes52s1nzyacgc3li1w00MQaj8tusEgjSG3E9rny6oojdghVEWz1oRojzF6erSUUTzDyUw6g/rTKWyasqtDcjp4TgTsyqe7s0D6B+EXWmtJ2/04zp8mpVVTJDiBWvXdIOd699ntRb2sxdcboQBSPEDLc1Uy7NS+GL1Oki9ZLN+yjrMUQnYS/Nn+pPBEwWl31eORAWHY19vovd+f7zMbbo20U9L0LuV67B3NZ0/wsy40oAgRx9zd6yQGpjdO1QcWI8P2ODPAMybE0Zv3rCo360vf3jNjn1QA8ZvyPiRCVQanEZmboDM/YNImaNZP0RDOlrkQpJzBjndO13/EOEtI12tOSablS4iNM43a6M5i4AqlRRVvcIl6Fg8L5vJjLtkqzcOqInbpsh1x2t7gnFNbMLHkwzvcdryoNt4i9MutZmYSmqXPdxNiCketr+Re0ALJ172q+tVut8wVV9uRpiQAGNxcj8hkdOlW9GsoeF61VYU6mQnJS1FePYV2+O3oM84yRHrElSRGOVIhPbYKr0xsy7Xfn3NcyPS9a7pqZULqLx364qCv58JqMLaX8Kgd/gfpfadIyYFc3/ZdiLYYoQ1LzsetoWd89oQfMSQLT9QkDdxfiMIEmpCJcecpW229VIhA855e+t6PZNiODfH2UXJuAidEQjbqycEMTYtc8TyUZ1dW9kpGj6SbacRNeXrzuTnN5yEofzOnVj3pAFKjMHQlgDgc029PIkvy8HySvEvcP1D1dir4zYUxofv/AZNt7iVzgEDveZqkE0vYE4xAmw2BRyQzLIiYR2KeMYBWqEAMWCVDIth5BTvVcXNyPOGQOyvm70khb1x6GTLSCJ1D PeJQ/Rth IRTouEKpWK+QM9vWhXcFeWnBTysEXg/6hXnTCtE3JifCv2Em6Y5XX8m/dkam1/e74RSHmvRnvDUqEhrsV0lApR2ZWE2bUf4QcWyDWkz04eQYpHMWTgchNo7BQPLvhRiEaNGz24vWFNXsA9XMhQCsIySwaCf8/0MaK4Eyk/JjbHwgPsUDT0nXLn877yPwmmll00qglmnkkCnrKyRRlys6vQ61nTAxpTyD4wQqI 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: Hi Muchun, On Wed, Aug 28, 2024 at 10:36:06AM GMT, Muchun Song wrote: > > > > On Aug 28, 2024, at 01:23, Shakeel Butt wrote: > > [...] > >> > >> 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? > >> > > > > 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. > > Hi Shakeel, > > 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? > 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). 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. Thanks for taking a look. Shakeel