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 A5181C3ABBC for ; Sat, 10 May 2025 03:12:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CA476B00CF; Fri, 9 May 2025 23:12:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 679CB6B00D0; Fri, 9 May 2025 23:12:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58E0A6B00D1; Fri, 9 May 2025 23:12:38 -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 3B3DA6B00CF for ; Fri, 9 May 2025 23:12:38 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 15FD8C131F for ; Sat, 10 May 2025 03:12:38 +0000 (UTC) X-FDA: 83425525596.23.69CB1C2 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf17.hostedemail.com (Postfix) with ESMTP id 1525B40004 for ; Sat, 10 May 2025 03:12:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=iJ9Dn2q6; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf17.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746846756; a=rsa-sha256; cv=none; b=V6/inxtN+2kPI1b5o7rmhKaMduyma6wUVDf05Xzh8BtbXbXFWJ+nO4EYFZDAC5u7dI6WNO xvZ1ePUGhsfrxJqv/GghbmHPyRH2K2xxCfTVD0YX81nTDNSXSWlgYH7FzcPMvYsVV2abJF y2S6ivTO6rBsZN7SyjlKSxcaJVtiNqU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746846756; 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=JiEb5YARkO2I8m9A66UGcmQ4V3Z4sE94ND81dqX+dO8=; b=d9/bv/YgdP9Zl0Y8UJZLiPIK8Jv2zX+nlGLwqox7uZvKlIev2gnr4/r8l5gaO94GvAFUy6 2NdX02sWL4SMiP8sx0FBiod4jc7SkMiGA92b9RQ6nsgBQeZgFrZmWN9mOWcFVRDQEbQTCK 1OKZvSjWi05CkFg6Ngpw7dEnS6rK3pk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=iJ9Dn2q6; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf17.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev Date: Fri, 9 May 2025 20:11:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1746846754; 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=JiEb5YARkO2I8m9A66UGcmQ4V3Z4sE94ND81dqX+dO8=; b=iJ9Dn2q67WMEAPWD03Wr+NCVGG1K0ctFpYfjkOrA7o9w2bUsBo6t4dz3iBQgZBUFlFlOyD gNFtM5MoreKTji25JnyAaUyofLbxs8dlRmUNIqXMM2EA74KDxsQxeqw43SZwQ3mUrSl0zc Sno7ZsJBmrBzBEgdLddC25+2UZ4bqlw= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Vlastimil Babka , Alexei Starovoitov , Sebastian Andrzej Siewior , bpf@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [PATCH 0/4] memcg: nmi-safe kmem charging Message-ID: References: <20250509232859.657525-1-shakeel.butt@linux.dev> <20250509182632.8ab2ba932ca5e0f867d21fc2@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250509182632.8ab2ba932ca5e0f867d21fc2@linux-foundation.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1525B40004 X-Stat-Signature: p7yc8eqs4kdqwkirfu1f19mxgz7y3eq1 X-Rspam-User: X-HE-Tag: 1746846755-62792 X-HE-Meta: U2FsdGVkX182wohormhttWcWT4PrUnh6JbPfUG1Mtx1DCoWFt9stQ3Gjndumthp4vYj+KHinsaKvK8rag1eMu6xy8f4Cy+/84QiiUlTCR1E69A7ngOaNNJrYIfis5cFgVR1/uhdqMh0qrJ8Z9HhQRXo1TKvS5kRUhmBeE5fhjRCTBKNdghXDt7g3BhoF6ULFxUk2w+bKjUtauJbK9K0Dp276MkeSvWJkeStASCPaki2c5fRPhQuaWMypvYNHsQmPEuieuKP9Q4bEyN221mCeDkI4UuF53EdQaNscw7Z2L5VOzY+g0kOAb7LOqosj23puexD84uI4Zneyo5ZHK5ZBQoUR7vmffoSvrTs6HiyvQx7h8V0ALwtpTe/4KbSK4tljcLUazsEU7eol/VZ6w5AUR0e0Ofg71SOzc4no80hCS7/l25ZMV0Lwfi9AgSnriTadYbAd/o1fFPbwSJPbXhoOiZT9MDQ9EsRV49wXRQACw1AUct20C8bPuAK9R9e5d6cN3KurnRRL/d+gkOO+c9OgwWJnA6cOcutY2a5sR9+IkQEH6u1MWZdw+L9Tl8oJFqXbMzG7738V3YdEBtQLbIfwUB5Rd25f+NaLF5BHpWBlRZvzOaH+Q8+wVs10YBjQ7s0bf+I6vOYNjP+dvJwttDoMRWaJi5OavVCgKho87gk63D/2eZVXhNw5QQ0breId+UoqElmhX9j3jkERYVCGWnFZYNsLx89eoT+hQozb1jJ2JeZv31fstK7wGn5bkTzGx9ty1UmdaKrVMS/wvqsGvexaJu8v4ck3Sgk59iYj4GWBiqjqCO4kxZgmrvpdh0tF1zwfQ1fPsrm+b5Qhf9AU9NSY9iScJWp1mn9EE57mb2gJufekS42jBZUiuZXOM07cKUbLmkOOgn3HDOzFMZYCQcYSjNHxyE/FS0N1dqbCzU3qp7QrDYVtu7gbBNSlJDqFT+d9YqggK9mteYRVf5CRE3E rtwkSy2q C68nuRv9yqWi/lcANzPwqCci7Urbt7WqfsES9YMoC6m4v1RCihdF14K7HjHK1i79yuFcE6PDIuYQkvkqWKgC/MDK+fzLKbDVZlajQQlToBtXDkYYH6bnubXb/Vq8Uimk+nlBVKrtVqgEcBfzJRrQ0uo1jOW6aFrcxAQqFcyPH81Ak812Vra84MchXvA== 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 Andrew, On Fri, May 09, 2025 at 06:26:32PM -0700, Andrew Morton wrote: > On Fri, 9 May 2025 16:28:55 -0700 Shakeel Butt wrote: > > > BPF programs can trigger memcg charged kernel allocations in nmi > > context. However memcg charging infra for kernel memory is not equipped > > to handle nmi context. This series adds support for kernel memory > > charging for nmi context. > > The patchset adds quite a bit of material to core MM on behalf of a > single caller. So can we please take a close look at why BPF is doing > this? > > What would be involved in changing BPF to avoid doing this, or of > changing BPF to handle things locally? What would be the end-user > impact of such an alteration? IOW, what is the value to our users of > the present BPF behavior? > Before answering the questions, let me clarify that this series is continuation of the work which added similar support for page allocator and related memcg charging and now the work is happening for kmalloc/slab allocations. Alexei has a proposal on reentrant kmalloc and here I am providing how memcg charging for that (reentrant kmalloc) should work. Next let me take a stab in answering the questions and BPF folks can correct me if I am wrong. From what I understand, users can attach BPF programs at almost any place in kernel and those BPF programs can do memory allocations. This line of work is to make those allocations work if the any such BPF attach point is triggered in mni context. Before this line of work (reentrant page and slab allocators), I think BPF had its internal cache but it was very limited and can easily fail allocation requests (please BPF folks correct me if I am wrong). This was discussed in LSFMM this year as well. Now regarding the impact to the users. First there will not be any negative impact on the non-users of this feature. For the value this feature will provide to users, I think this line of work will make BPF programs of the users more reliable with better allocation behavior. BPF folks, please add more comments for the value of these features. thanks, Shakeel