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 49618E6FE34 for ; Fri, 6 Sep 2024 17:19:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D261C6B0085; Fri, 6 Sep 2024 13:19:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CAF5F6B0088; Fri, 6 Sep 2024 13:19:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4F4F6B0089; Fri, 6 Sep 2024 13:19:58 -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 9133A6B0085 for ; Fri, 6 Sep 2024 13:19:58 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D8075A9DCF for ; Fri, 6 Sep 2024 17:19:57 +0000 (UTC) X-FDA: 82534976034.14.DB0565C Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf22.hostedemail.com (Postfix) with ESMTP id 0F5ADC0017 for ; Fri, 6 Sep 2024 17:19:55 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="SZxG7mw/"; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 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=1725643170; 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=zo6fqgtuuFE4NzO7fsVL9VZI75GyA9ZRT8MrykdXVx4=; b=dKcdiSYnoLN4wtUvUUn84KfxHb4DoTyCBcYp17rIdFCZa6F9xaCx1Fap/fQ7531z9AvbI2 pY+aJOXa03sP87nV77HBaZV8Xne9UOHloXMxfo3wNaPWu0kWftHntxS3L+am/SA7kISHNY ESSA6S2NWIvqkGuqpQZFbyCNWlwjm0A= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="SZxG7mw/"; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 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=1725643170; a=rsa-sha256; cv=none; b=FFWQ+TaVSCPtWDC6jIsTb9YbCtMNONCcWpYFpfhWOMFumPyPEFvPAM24dxPAmpL1ziZGnw ODBULhD9S4mvymhStuHU8RhkKklPC+09dS4tdDUp/wCHIXEUqiJ71xHr9W2WqyZIzd9ULN HE6Z2x4VaVQMWD5dsQe3p4al4BXfsKo= Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-a89c8db505bso310262366b.0 for ; Fri, 06 Sep 2024 10:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725643194; x=1726247994; 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=zo6fqgtuuFE4NzO7fsVL9VZI75GyA9ZRT8MrykdXVx4=; b=SZxG7mw/gB4sCnCaBQbra3nznbNqluRq3W+e3FB1k596qVXeyD2czfgx06Ffg597+k 7k3p68RzZUX0wmGlAlzTp4C3xE6NEoGV/iC70HrFH2KLc6VrKxXJ5izyYMPFFjWL/5pu gDiq1WDHdJhNkQG5fEUF1vSsp+OpeNFDLZfwzpn9pqPdMKFpjmAsOw7I/lwsjDPU3vFo YKGnZLo3qUxBSnoTErQSCYef72X+mG7c0CLV06mjJFTbS9T3lizUcJ36H4+qVB/UeS7Y cVie1X22MU5o+v4ZeeFhDLUvv1nvCO3xOFooSbp8wjyDTirVAfKKLtzXlRsBKTr75z0g oc1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725643194; x=1726247994; 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=zo6fqgtuuFE4NzO7fsVL9VZI75GyA9ZRT8MrykdXVx4=; b=NXE4zbVwS8CSJz/IGIalVC99AjhTTt3uHNzm7VysVh5C1jTC4nCZ2lCHhkQeJxO+rk cagATv1zbXAkCanvIrnNmgQhXcz6nQ6gXgI7oG/EGzkyu4Bnz2aT/Pv1JEw+lhwEO7g9 S21g08u4rWjPW9f/schs3rxH5lzazKz/3wlsmqPsvhnowrRxCBGM75fahpk4a0aAtrnR fkUrrwKcrdKoekKnanidslLNaCb/Vdw8dgxI3bTqD+7GOJ0umJZBnzGn1fvV5IrxRqFJ exc7pWE5kAF6X2nIcYudmEnAKJaPkn+5YhCStppGShqcFCrgmWrZUVVVvV82hBR4vjKI nXfA== X-Forwarded-Encrypted: i=1; AJvYcCV7REnUcKknccjmHsIRftvCJ8cKsdpBUHBJMKigpATcK1AvnUVbOGfw8c2QKDrICxUJE9ylqlgZ2A==@kvack.org X-Gm-Message-State: AOJu0YyFQVex9D+f97dc6Lxn2pi0aiXZ56YgojKhq4syAKQL+HO164QH p9XGGSlFCAMwHaI+aeuqTWu5YQfB79cm3KUnhXYHv8GqQkXWVrqz4SfDM1YYPWYy8sa+wiM4rjL JApmUygh6QE+tl3FqsdXtDBvInqvPD2GB+Xyd X-Google-Smtp-Source: AGHT+IEmGTsFjxloYhTWQXuny7JmM5MPPjtcCFZVfITmMThbDPUbvpM0TFPBX7c3l7gb/TUFCOc+yz8f2fGvO/CXoLo= X-Received: by 2002:a17:907:25c3:b0:a7a:bece:6222 with SMTP id a640c23a62f3a-a8a885bfdf7mr270126766b.10.1725643193288; Fri, 06 Sep 2024 10:19:53 -0700 (PDT) MIME-Version: 1.0 References: <20240905173422.1565480-1-shakeel.butt@linux.dev> <572688a7-8719-4f94-a5cd-e726486c757d@suse.cz> In-Reply-To: <572688a7-8719-4f94-a5cd-e726486c757d@suse.cz> From: Yosry Ahmed Date: Fri, 6 Sep 2024 10:19:16 -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" X-Rspam-User: X-Stat-Signature: ocbuoc9poru3835mjc4ispp8x376s13d X-Rspamd-Queue-Id: 0F5ADC0017 X-Rspamd-Server: rspam11 X-HE-Tag: 1725643195-322484 X-HE-Meta: U2FsdGVkX1/R3jJ4z+/N+wMUJblWwlLlMJQyZc8ge+4yk2gPz1q/8rPDL7fWGu3iXbtmGwMWeUnoL1wskCIrg53fHyEhyvHc0B1+1053y2VMpMD1oWZ8i18/S4wH3fafSC68njSdyylKL2HJxSEpm6cGz2Xu4ngoO+6RaBb2+nqjHkC7vSCGIMUU+03dMIhegjvPf/pS4hxrAwdgjFpwVg+GhdoHm8FCisG5KOkD8URrSkYC+Yc15i/2AQ3GWbkOYVfo6o6KXkUP7qn6c8IXbcAegt6gM4wC69hMPW1iQf66PcDQbxD/WbLW9rQKw9M+YGqOjANPkixypvjYXy5Chq6gD5Pydr2V4nQ7kl5g0oxkPr3998pqK8EDiNPooh6ebOYWWRMaTTHNOkYkcHuaBPNhL6FJQNQ7Xs9qLWc9QRgI0eI+zHWDVYQjk0JTnnL/E7xgZpvGuZ6ak/uxIf25TpeWpl1wJm8bYWa7wrbFg8tsUxk0juOJ1xVHNRmr7zFbvxqtcHrlK865HLFCYjUd4F8IsmVWBICUrGCPdOHxDfQJqnUwTVUjBGseTvh5C7SweAsIT9RFAi65Dizyd0/JwfdEZXefEhCMFzLMdy5qxoKyAEx//pIcv0MkiF3q6AmhWJURjAf5X3epNDzDz7haBDjDIm2ggtB+3CKUDAilrfi3M/xZVfmf7fmaoWlX/YjqDegg5bsf4iLJgKD+PJmsAsrEJQSMW7ptrRv2zdKFpT8i0tc6wQGGnxe/K07pOxdBGUteSECaL6n14sq3yKjv83Z42dno7Qm6JdrRxGF9T1yF/azkQk3cvMKXsyD+cLqNK4Y+fuOKnh6SC2YtjsRc6FWFsvaOQegGEYSwDWUUT7YCSQt+n3Hx3D1hByuCW4YK370wWB5ngVxPtucq6TIQB/m+RmJ+qKw7ovcMyi2zvibyrxHjqbhXJ5LGDm1kEhrNFhkt6PNHHtdqLIj5oDt r+rJJW93 fiM2ti6s/2f+9Y1UIC7xatmcF19eNsrfCmg4dX5okqURY3OuxF9dlAZLXOAVYDcX4Ew9v5sAxaa6eq02HznatLkdZxLzMz2CpVGygV5x+Q3x14P26DaBjWBD8WBRPHu2SJThzqYjDptBzej23Z2413uDNGKdCVzFZ6OPBQFVsQvuemys4J2QNzWb4bNvNrfKGdlAWom23F9MCCczYQL3cfasudXbaOWoDuLBIg/L4tp54DfUJX+2Y8Mi7F7ZcuDIWIj0WAKLoh4Ez1k8= 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: [..] > 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 memcg, > * primarily in cases where charging at allocation time might not be possible > * 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 memcg charge Aren't allocations done with kmalloc(__GFP_ACCOUNT) already accounted? Why would we need to call kmem_cache_charge() for those? I am assuming what you are referring to is kmalloc() allocations that are not fulfilled from KMALLOC_NORMAL caches, but I am not sure how to capture this here. > * behavior can be controlled through gfpflags parameter, which affects how the > * necessary internal metadata can be allocated. Including __GFP_NOFAIL denotes > * that overcharging is requested instead of failure, but is not applied for the > * internal metadata allocation. > * > * There are several cases where it will return true even if the charging was > * not done: > * More specifically: > * > * 1. For !CONFIG_MEMCG or cgroup_disable=memory systems. > * 2. Already charged slab objects. > * 3. For slab objects from KMALLOC_NORMAL caches - allocated by kmalloc() > * without __GFP_ACCOUNT > * 4. Allocating internal metadata has failed > * > * Return: true if charge was successful otherwise false. > */ > > >> > + > >> > + /* Ignore KMALLOC_NORMAL cache to avoid circular dependency. */ > >> > >> Is it possible to point to the commit that has the explanation here? > >> The one you pointed me to before? Otherwise it's not really obvious > >> where the circular dependency comes from (at least to me). > >> > > > > Not sure about the commit reference. We can add more text here. > > Vlastimil, how much detail do you prefer? > > What about: > > /* > * Ignore KMALLOC_NORMAL cache to avoid possible circular dependency > * of slab_obj_exts being allocated from the same slab and thus the slab > * becoming effectively unfreeable. > */ > > > > thanks, > > Shakeel >