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 56BD7E6FE35 for ; Fri, 6 Sep 2024 17:39:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0E6E6B007B; Fri, 6 Sep 2024 13:39:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABE7F6B0083; Fri, 6 Sep 2024 13:39:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 985DC6B0085; Fri, 6 Sep 2024 13:39:23 -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 7938D6B007B for ; Fri, 6 Sep 2024 13:39:23 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2B25480B3C for ; Fri, 6 Sep 2024 17:39:23 +0000 (UTC) X-FDA: 82535025006.17.2B3F57E Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf23.hostedemail.com (Postfix) with ESMTP id 3CDE0140017 for ; Fri, 6 Sep 2024 17:39:21 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2KcwAxOa; spf=pass (imf23.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.48 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=1725644230; 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=4eyE0YvwAJ4jbuy5OCYOQlHJiaipbu47/6EmzS9gI24=; b=j1ELo1mpAVVyWxtPiEh8N+9C/80z3o9Cbs+66S24KG4we6qdaN0yZ49lvdnOTEMWdZUo/E bo6iac9dCjpbkWT6kLiuRxsoGtt8zc1e0rYQdtmoxgJfonTU5gZzNxyJusVe1lhrgup4FI d+i4rdvqt2ySRTULcXXEiUZLUtBXdgk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2KcwAxOa; spf=pass (imf23.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725644230; a=rsa-sha256; cv=none; b=LbKtukH8mrA0rtsm6p/LHY5UJ8QNWCwRfjhGxnDHyENm5mYZRIeuG9w52Gikq6WjZuNTtw dGIK5go0xOiF1YxMhkgLJlBKyGMRn6IxW9McrkD9/nY5L4CQfkL/XfRhSTyn0ZqjozyDdA a8mRmZ/qg3AjmrK7rG9kJEVTRQC+/ug= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-53659867cbdso1443636e87.3 for ; Fri, 06 Sep 2024 10:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725644359; x=1726249159; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4eyE0YvwAJ4jbuy5OCYOQlHJiaipbu47/6EmzS9gI24=; b=2KcwAxOa7RJ8hjKzdgwabgNdq/wJ65EHGgxO1E88KT4dGgaqxLm1MGTVqFkypD4aYY JddVY+14NAwX9Tb/PG013mefsQg6ewbyYolssPTrTVgxgcjxBEoLlcA87W+6p74z0y5A Ao705DxXPmZ9fchaSp5SV/zwZUMtBgBQoJkKMcUx8TOgrd34S/aSkajvX15gGECGPDER kKCxsjSNgQYrHK1QgW6edRe3UYTsx8gjW7/kiySVyS7kuZlT2fk3muF1PCBkcQta0HYa fBp6vkT1lBBtUVZnIIJRLKcvMQmUZjIzybxFtM4XixT2MTZLrdnu+j37fkSwuUppoFMf hGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725644359; x=1726249159; h=content-transfer-encoding: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=4eyE0YvwAJ4jbuy5OCYOQlHJiaipbu47/6EmzS9gI24=; b=ho7ec6x3dhmCUcNi5BBAWel4Kj9QdwMfADcX70wP4eLMsCPi/A/x5X5T02R4fIx5nD C1y0Jqzbc5z3VgrpCe0cDcTMjC5qhbVPmW3jR9IFqL/SLIlF4M/YW8dqIYRNP8uYx9YG tvnBBy2Qx7tXVs1iI3asf6MQH3BaThkYFVWQylaVU5I5J6zufuIPIvYcypaz/ng0Elxl 1eH88+mwKNKpVALwXocPoy6o19mDngo+JvzYSJD8OXXh0lGgF+3vVaOSBuxRiih/VH5e 7ydmx6Rn492vy43YS/jxbX2XdYPf3fN7KknFtEG3NdlSfn4lwiEiwiKQSQuiGRFGsRDt mz4A== X-Forwarded-Encrypted: i=1; AJvYcCUHNhTYMstBFQjfPMBxmVr5Fq+9/J2KNxVtfKM1MnvxX0v4Wi5CY9zJXCJXuvdD12VP1EIBNWDVTQ==@kvack.org X-Gm-Message-State: AOJu0YzNBUdwQDuWQe9FY6YpP7TZHzmB0yI5FTVgg/CHHf76aXSaAbxQ L6cJwr0wW25f4z/3a9Ll2m78jNXjYv0PqXWohRKgIRKnYwoedZMyY9qKMqguX01d03A/vcYMP14 C8Mh8RuP5aLLb3c6ydWk26L8WwTssv4H1F6jG X-Google-Smtp-Source: AGHT+IHipKO9SkosIPD2Wct73/XYtbbx4G71uCj3TqDiza68oFp8S5K1JEdl2VaO2MjbDdeU94o3UF6HlYNf6nqPKYQ= X-Received: by 2002:a05:6512:104a:b0:533:4591:fc03 with SMTP id 2adb3069b0e04-536587fbcbdmr3255522e87.46.1725644358377; Fri, 06 Sep 2024 10:39:18 -0700 (PDT) MIME-Version: 1.0 References: <20240905173422.1565480-1-shakeel.butt@linux.dev> <572688a7-8719-4f94-a5cd-e726486c757d@suse.cz> In-Reply-To: From: Yosry Ahmed Date: Fri, 6 Sep 2024 10:38:42 -0700 Message-ID: Subject: Re: [PATCH v4] 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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3CDE0140017 X-Stat-Signature: 3x9gjhdsftuesafgi8h6457zjiscfmg3 X-Rspam-User: X-HE-Tag: 1725644361-701755 X-HE-Meta: U2FsdGVkX1+XkuWGG8qTsLcxxaU52SwD8M0Bamut+fc/VioMrEoPqwb84erD5afN3cWPPUKrDCyny02//vrLWWfcDp2WBNWb+p203rD9MWm3rbVLMmTSUfmgXHTxWc9/u9XlMjnlZhzYv5LD/wmXUlisubnVizIoXQsObn9zwki5SJ7vvR4HEAAMswQ6LxfnOom1d3uqCK6jPfY3IlGacrgqIwvdepDt0hc67lRb3/DrJNr0TTl4Ce9db9rnHaLYofGbR3+hc4YoNeMlOZnRO1yQKC2N7Y178LPIoxhmaGmFfJ+J742vJ93F2gM90BRKlSdCdTX161hOWNfXp8Ncf4m4oBNm8qC0mF2l4UjGaNFGQmEY5NDMqoi1vsyoA3Lk3yeyDMSVCw1iZu3I+obVVwQlyvwAQCNGw7uZD6kZkoEgebU4TsiQnZEd5QrgnQ3odGPipN78jKzNvkYo67Q+Pto9MCREZnllbrRtRSQJZ+9DS2VvX8wxNzs0Bn1QFc3vTAnKZrB3ch2adPJdeeCT3q30Oc32Ogp8wofI+nWnJV8R2kvG0PlXvB7dueCvKrbZBUH6pKQgXoxPQAGmMW9eT07HGNSOCvtv5kaa14leU+X6KCoLYXmixdyyV13kDEhxJFPBDcTuXoRKPO7Y0PkqTRTO8GABrfIotx0j9PBurwhOXRkCkTGrkxD6V91jBX1O4Lnr/a+McBli2QqnKvlC8/HNXl5qEKhPoBzUJrqCel3wog1QFw9ZzQ/p7mSIC5cG8HFs3z8xNXVsVjO03jxI2T8YkpVwe5n4keHYl9bKv5QVrd7baiOtyQWtfR/FtqAS6lwnBtWamoe6j3w2OF5q7UWg39HgV4l9m2rJhhXkN4tYwbAZGTZ459kRkQ+912HU9vdVvenLlIRJctjqL5Wdoz8Tv6x3oLQknZO/0EFIKgLVZeyIsm1ypZOarveE07dr1JYrxVOuIB2uRzCGR3m rxXWOD8t pHAbpUPqxswHeTA2LNGDWmrtaEPE9aASRDyeNoRYlpJEDAPBvILhbN5tLnPc2i2qYsW1IXxpUsDhugWsxF281JPvA3+VjWsBwXNuXUnm7Sbn0zfO/m7iXT1KnPanj0uVqC/uLFBJdc6TtVSVdrVx8blSHJJBlYrBZafWLtFOBLsH66l1xbhuOjB+xAsI6pleOpwJbSctDThYuYbqwUG53DWBiXs2EYVc7K5Wq6PR4U8Q73j5RmneVdtBaVQ== 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 Fri, Sep 6, 2024 at 10:29=E2=80=AFAM Vlastimil Babka wr= ote: > > On 9/6/24 19:19, Yosry Ahmed wrote: > > [..] > >> I felt it could be improved more, so ended up with this. Thoughts? > >> > >> /** > >> * kmem_cache_charge - memcg charge an already allocated slab memory > >> * @objp: address of the slab object to memcg charge > >> * @gfpflags: describe the allocation context > >> * > >> * kmem_cache_charge allows charging a slab object to the current memc= g, > >> * primarily in cases where charging at allocation time might not be p= ossible > >> * because the target memcg is not known (i.e. softirq context) > >> * > >> * The objp should be pointer returned by the slab allocator functions= like > >> * kmalloc (with __GFP_ACCOUNT in flags) or kmem_cache_alloc. The memc= g charge > > > > Aren't allocations done with kmalloc(__GFP_ACCOUNT) already accounted? > > Why would we need to call kmem_cache_charge() for those? > > AFAIU current_obj_cgroup() returns NULL because we're in the interrupt > context and no remote memcg context has been set. Thus the charging is > skipped. The patch commit log describes such scenario for network receive= . Oh yeah I missed that part. I thought the networking allocations in interrupt context are made without __GFP_ACCOUNT to begin with. > But in case of kmalloc() the allocation must have been still attempted wi= th > __GFP_ACCOUNT so a kmalloc-cg cache is used even if the charging fails. It is still possible that the initial allocation did not have __GFP_ACCOUNT, but not from a KMALLOC_NORMAL cache (e.g. KMALLOC_DMA or KMALLOC_RECLAIM). In this case kmem_cache_charge() should still work, right? > > If there's another usage for kmem_cache_charge() where the memcg is > available but we don't want to charge immediately on purpose (such as the > Linus' idea for struct file), we might need to find another way to tell > kmalloc() to use the kmalloc-cg cache but not charge immediately... Can we just use a dedicated kmem_cache for this instead?