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 00584C8303E for ; Thu, 29 Aug 2024 18:29:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D8AB6B00AB; Thu, 29 Aug 2024 14:29:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 787A56B00AD; Thu, 29 Aug 2024 14:29:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64EA86B00AF; Thu, 29 Aug 2024 14:29:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 464E46B00AB for ; Thu, 29 Aug 2024 14:29:06 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E94281407B2 for ; Thu, 29 Aug 2024 18:29:05 +0000 (UTC) X-FDA: 82506119850.05.6997620 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf12.hostedemail.com (Postfix) with ESMTP id 1B7B14000A for ; Thu, 29 Aug 2024 18:29:03 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zP1zMI8v; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724956056; 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=uFlJynURVWC+M2UJehrQrk5CWf/a/Gwly+Kkpykmcts=; b=UGyjTy15HC+dGeLy9W5kMstf34wWnaJiQM0AEc9Feu0pO7BWMh0Me/lw/iLLPCKdnv3eIc WgWJk5sH6a75SYr1JpwA75ShAw16dbAex7rAycWJcaGXBRNVUyOMcik73PuGt1Jgc5s2/S BtClRM1wymgaphx8txh7GqpIPuKL1Sg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724956056; a=rsa-sha256; cv=none; b=MT1jbe5q5uFg3fuvzP5m4wmTxtg4zdOV0GKAmd7nIV1syrnnp/C8WImr1OK6Bl608B7rvR XPLggjVvBupRhF4AYARf3DBln3r6E47NY1jKsivw5YZCJRE4riDa9MtPukoFmVihUkfH5K CMMumY7jDFbvDOluS8x66kLKyPik6Sk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zP1zMI8v; spf=pass (imf12.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a868b739cd9so126785666b.2 for ; Thu, 29 Aug 2024 11:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724956142; x=1725560942; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uFlJynURVWC+M2UJehrQrk5CWf/a/Gwly+Kkpykmcts=; b=zP1zMI8vKclftrUhB15Yj8ecEvfUNJHVv1SSJThyD5TO+ylUh0cfmqKyDV/gL5+Mx8 9Eur0Hm+2YRc2XZdJAjYheVnCLyAquKaLkzLoFdHw7i85XUjt0UOrUpcdspbtZG7IOtC cbWrS60JpehiqcsDsX4D5l32XYxCDgRTnot8kAfzBgcs2xlg8bugdfUDCIzedJ7VKPFU wdADiAzF3vrMu4soyEDv/2IudJ+F3C7QTBz8PFr2V8Rg3fuD1ZvyXaZbYN++Xd77F07f xcfoxGeVioSl0w970A2b21ymRmWyMblW0SmgMMBUGeAgLU8jE8Zu/94LyhWbq7UDhZi1 sy7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724956142; x=1725560942; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uFlJynURVWC+M2UJehrQrk5CWf/a/Gwly+Kkpykmcts=; b=n9DgLUaE11PFBnUraE4co0SyCaA+JX0nO+b7ROzMlT4RH1xCOgFDK5VoMvl/z3o2yc 9aw/WYCf3CnkaGCl1RSvGGw6OpgBwWw2KS7SA/Oj2hr7fjLEJidl5cJjZ9PPuyQcB9u+ Db3mh3nruWxNbH5SoLKdd08FXNZU6FZz41LJR3ugGnrrYCxZiiY+kGJJb/BKa1PpJgyt 2ZEpleDLW+eBHxpc26EO2uST0gLzgeSmaxFx9KqOSVuNQbko8Pey1NA5LliEM42B0/dr 5QgJTKtF/NT2Z30kwOlYZu3pBu1nHyoIZOoh3MiwxUPLBSHaFB1FVFlSQ/IKJ84vOi2D rsTg== X-Forwarded-Encrypted: i=1; AJvYcCUz+yT77K5+0TSrxkBYhU5Y8VCav/cmHR3/uc73iYkS8NXFBT8nz+aKE0FIXoRWsS3hC7sxe2qadA==@kvack.org X-Gm-Message-State: AOJu0Yx/cm9ofYguvlgnMrrq5P2Fl+APi2eqJsnz9bVDigRKjaWjsx/f wilPhgUmf5AfiwAD4OO/11Lb+SAKP9Ct3uzjfwhGPlJPzTwJ/Uo8MXjcjGIyuxW1K2mCqNvly0L NKBJc2EXWMer/jPMskZz2kAxGfNqgZXblRyPC X-Google-Smtp-Source: AGHT+IEjCsZ5C7DEJGtuDAb8jQenH6fq4Xe9rcECFO/np82w+7fJUFxQQ/NSCKZtW9cfxdwYkeCFsnLIObrWOWS1Sd0= X-Received: by 2002:a17:907:868a:b0:a86:9880:183 with SMTP id a640c23a62f3a-a897f789550mr277753066b.10.1724956141671; Thu, 29 Aug 2024 11:29:01 -0700 (PDT) MIME-Version: 1.0 References: <20240827235228.1591842-1-shakeel.butt@linux.dev> <22e28cb5-4834-4a21-8ebb-e4e53259014c@suse.cz> In-Reply-To: <22e28cb5-4834-4a21-8ebb-e4e53259014c@suse.cz> From: Yosry Ahmed Date: Thu, 29 Aug 2024 11:28:23 -0700 Message-ID: Subject: Re: [PATCH v2] memcg: add charging of already allocated slab objects To: Vlastimil Babka Cc: Shakeel Butt , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Eric Dumazet , "David S . Miller" , Jakub Kicinski , Paolo Abeni , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Meta kernel team , cgroups@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 1B7B14000A X-Stat-Signature: bnfht816j9hnk1tf1mapr3rd7a59t7ar X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724956143-537029 X-HE-Meta: U2FsdGVkX1996esnwtyusWUKHKudtmp7Wsm+rl6wfaICz7t/l86P+D5qQltriFw+NtUHIx1j3d1HFahmBCLMemJ+gnvvqmX6i5I2wavQwAT/llKdhNGlqV6RtrAiz/drjdszEKzA1oDgI0r61rfSjcvBAdUnLTMgt7OaZ9CvEdJe/UpOm8GZa9SM22RbYq/qbDeWtEWhjAnaawGAfxGmYQcLGQoONwZT/v5uOl3VGw0Ex+O5UzsLcJj4xBzgBfGma2WM3KIs60P2Dg408bF6jYnNMD6g7azGX7X4NZcOo2XKJ56RFOHwGfWNu2wmXw9cYApRyTIVH5CCEtTe6AhQJ6bxvEV4/h9GBQg7x02pqblrvqMzcUS+JbYOmzTW/7bDyVY52tcqTMquR5O7Ecvv/ITLTp7AaPi9BmyQYtcRIoaadPG5+ZhNw0ZaMkjnybKBmJ9h7NWJIMceoa4KZIAVxTYv2nIAjF/Zw7M3XtA0Ro07Vz1mKg/4UUZetVqROv8l+rg09o52tgaLZIaF7v3CRbB9FcWhbr0NmBMngQNqmNlhLfpqde1icibdzGrBvrNqLMk2wYNBq4uPHDk/t5ZO5p/fPg3Ll+HD08GsLOj6Ex7uRklaa8kT62xWKJn77rQsz9csVGymhdGx5XWhC8jGjqE0Pscq6f4xC5Uy4Pwutp6v5lWFeHVNCPBxDbf+a0/7oLV6oi5rodFSoQ7WUBTL8R4Ba2KVajdvjv/oXSoYtQ6wZ0m6GkLESkSKjz8ADbHx7sFS+zp1iG7H/ABnyliI5AzLPcsIaYX5Z9wrSK27fqOEOdnhCTa6KPN0GRk7z3BTOrK/bMAJtoTb6u3vROl1C/aXvLWD/mzcmTUhfcJt5gpG5XAewiA5ez8pVKg5i8kKf1McK24oxxIxdvBLcVUjm7j9AelcbvIH7wx2eTuexuzQN4yfr16yOEcIJlSqKfrTOhxWBvylMEHlxWls1tL VUU/Rsot xwQoS1rSAInHRid1LTDkKsAf8FJiFIwFge1Zzp8xjoTQGQKyGp52rQ8rGJTqEErbbeY3BtjbQ0zZWZ1UXTOp9shLEyh1TmLG237deansBYDF38PiBoNoLTVeWYIzHrPEP9INGtQNYdcQ5u+nE0dtZfiGYBxJBrk6CGjULJlr7nt9Ll7wV+5CuWLKSMzIiu5ylfqgd4HQkhLlHfeDgTv+LFwQO1uvpmd8v9MpeRxzyfWT29lau1DhFm/b/X0clwVL5lHxjOCfOi2Jqio8= 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: [..] > > Another reason is memory savings, if we have a small subset of objects in > KMALLOC_NORMAL caches accounted, there might be e.g. one vector per a slab > just to account on object while the rest is unaccounted. Separating between > kmalloc and kmalloc-cg caches keeps the former with no vectors and the > latter with fully used vectors. Makes sense. > > > Wouldn't it be easier to special case the specific slab cache used for > > the objcg vector or use a dedicated cache for it instead of using > > kmalloc caches to begin with? > > The problem is the vector isn't a fixed size, it depends on how many objects > a particular slab (not even a particular cache) has. Oh right, I missed that part. Thanks for pointing it out. > > > Anyway, I am fine with any approach you and/or the slab maintainers > > prefer, as long as we make things clear. If you keep the following > > approach as-is, please expand the comment or refer to the commit you > > just referenced. > > > > Personally, I prefer either explicitly special casing the slab cache > > used for the objcgs vector, explicitly tagging KMALLOC_NORMAL > > allocations, or having a dedicated documented helper that finds the > > slab cache kmalloc type (if any) or checks if it is a KMALLOC_NORMAL > > cache. > > A helper to check is_kmalloc_normal() would be better than defining > KMALLOC_TYPE and using it directly, yes. We don't need to handle any other > types now until anyone needs those. is_kmalloc_normal() sounds good to me. Thanks, Vlastimil.