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 9DED6C3ABAC for ; Tue, 6 May 2025 08:55:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FD756B008A; Tue, 6 May 2025 04:55:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AD726B008C; Tue, 6 May 2025 04:55:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8F6A6B0093; Tue, 6 May 2025 04:55:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CAD1B6B008A for ; Tue, 6 May 2025 04:55:11 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4C563161F68 for ; Tue, 6 May 2025 08:55:13 +0000 (UTC) X-FDA: 83411873706.06.9DB45D6 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf13.hostedemail.com (Postfix) with ESMTP id ED25320002 for ; Tue, 6 May 2025 08:55:10 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tsF4BzGy; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0U7ROxq4; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tsF4BzGy; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0U7ROxq4; dmarc=none; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746521711; 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=/wZvaPqkQnpjjL6fqYURYkwEqQidRYfahw5sAAeWSuc=; b=qwY8sIeSvl4gczseDHc20sqhb/v4AUnadsDh3pLhG+rfhP2ugInLyeKEYtoEAsNlXWCw1+ OvHuAlZ6wfdt8qFUfuP2wVubXR48hzVSfH8cy4I0YQwnI7glQWTobZtqS7OFSqRCWRsYtW G7G4nRgAr9d3gUBy1lESq7avxp0Yf+s= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tsF4BzGy; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0U7ROxq4; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tsF4BzGy; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0U7ROxq4; dmarc=none; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746521711; a=rsa-sha256; cv=none; b=mn5rKPMK8/ftudYNYWo3mzdB46WeRsmWvWrU3H/Y574aQVErvCb2tTWXaUGuus38rQcMN+ i2FTQx9WUdQ+nEEdH8v7TBvrNyQl2BBMnZToxRsMIdEQxdeLU6j/iTLSV49U9JUzZu2NGn PlMYya/f/CmI/T51NUBWcsyGTTlWQFI= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 6AD58211B1; Tue, 6 May 2025 08:55:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1746521709; h=from:from:reply-to: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; bh=/wZvaPqkQnpjjL6fqYURYkwEqQidRYfahw5sAAeWSuc=; b=tsF4BzGyVmbKZNp6Ck0nNGKOd9uCZxLSb5wpGk/M2Xc2bN091EEBMsosmE+9yhWMp7ebEb E4rMJyTaub5cTd/bryhu36Sxj+nMAepyzJf8UMb9W6h/xsTSt8SCWlVZzSS+xUwxoKnPqb FOWIzX2GS2kOBKIcOa9Skck0kXL1yA8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1746521709; h=from:from:reply-to: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; bh=/wZvaPqkQnpjjL6fqYURYkwEqQidRYfahw5sAAeWSuc=; b=0U7ROxq4p3d3NkSk2v4YywrQgNIDfvjZypalqUZwWCdxDGUvbDftvWhs8PVBvVqTyqdV6x SkFmUSRY0BFgMGDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1746521709; h=from:from:reply-to: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; bh=/wZvaPqkQnpjjL6fqYURYkwEqQidRYfahw5sAAeWSuc=; b=tsF4BzGyVmbKZNp6Ck0nNGKOd9uCZxLSb5wpGk/M2Xc2bN091EEBMsosmE+9yhWMp7ebEb E4rMJyTaub5cTd/bryhu36Sxj+nMAepyzJf8UMb9W6h/xsTSt8SCWlVZzSS+xUwxoKnPqb FOWIzX2GS2kOBKIcOa9Skck0kXL1yA8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1746521709; h=from:from:reply-to: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; bh=/wZvaPqkQnpjjL6fqYURYkwEqQidRYfahw5sAAeWSuc=; b=0U7ROxq4p3d3NkSk2v4YywrQgNIDfvjZypalqUZwWCdxDGUvbDftvWhs8PVBvVqTyqdV6x SkFmUSRY0BFgMGDw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 4F59713687; Tue, 6 May 2025 08:55:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id yHdNEW3OGWhOYwAAD6G6ig (envelope-from ); Tue, 06 May 2025 08:55:09 +0000 Message-ID: Date: Tue, 6 May 2025 10:55:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/6] mm: Allow GFP_ACCOUNT and GFP_COMP to be used in alloc_pages_nolock(). Content-Language: en-US To: Alexei Starovoitov , bpf@vger.kernel.org, linux-mm@kvack.org Cc: harry.yoo@oracle.com, shakeel.butt@linux.dev, mhocko@suse.com, bigeasy@linutronix.de, andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org, peterz@infradead.org, rostedt@goodmis.org, hannes@cmpxchg.org, willy@infradead.org References: <20250501032718.65476-1-alexei.starovoitov@gmail.com> <20250501032718.65476-6-alexei.starovoitov@gmail.com> From: Vlastimil Babka In-Reply-To: <20250501032718.65476-6-alexei.starovoitov@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: uoqopbdc5ypz8zm4pbwi51w7r6mp3fwr X-Rspamd-Queue-Id: ED25320002 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1746521710-211853 X-HE-Meta: U2FsdGVkX18sL3MJm1D94kmZbrVDAICTkb1JL2SkChDNSc0p83oU2d07rPn4t1plXOqiXujUkcn3SDfw6gy9cD3DzvWX9edAYGyXZtc/pb3C01GXCqQDrQU0XP3VhCAXO87E5rbehtXw2JNvHDIfoKPKG6kRrZpt7ZXxryz8d9rBQ8GqdgH6MNlK+yhhaCM3usDSylKzdofmuzniwkLFujc9gi0F29Z/TzYpeYyIpcaxvPGPPFvPqESRWX/V3B4nqBNh8USPTg9SuavMcywGnodKorau1Y9oe5pofPF4FwfA/n/i/tMxgeJJM423OjDafk8yp0ETnR2NmaZRrpFou96SsZbcxAAYpFJz5pL5QajY2/h3P4HlZtV2FdXKydWP21v9Fzpzp/uZI/PN3fxWXk/OT5X+GWwmUvmO1oO9nBSKLUz+Yjoe48B1Ch6stYHKLZrJAKpn1Z0fsDoJ9eUhN0iJ1O4wzOq01pG6ZjNzLqIjx1Oe35ITeeNWyNAe7tlh0f9YklOsAUn29gAM6Pap9CTYyPp9CDS8znewwb7myWTHnuTNx+nQArdBxYey6ZZlZZBaHRJZ2CitTjp7y9rFeHMcUhMeeyAxUdMsPFj3ma+2NLnkT2n0JsQo7ofd/j1+qNtJ0AWU3R8FprV+uunGyWipYj74fSXd3WjrW9tAeWThwVIoqhtPLFK1H7YRNqUj8QDDR1zLozXPXOsTU1M/2MmyCIcC5gzo0FFyeEJAUQZIBv92rXCM3LULIcxiPxK8Qll7DX3fZPJ4EXQEsQG6brGF18Q4Ej0cuHFQ9WS3985xqjvQwh3P1Bvb97DXquXXKMNdUlfrncrgWWaw7DzfL/RUNIZXl9jz4D1Elr3vvSFZcZSoe9fD/NZqbv4QyCiEydckL6p0klh7q6ytuuDolHIk8i4qgnXWKmxA1GBL54SfBjxLUWUx5qJ//yIsxnFN4H7a+xkXmjB6R6NTVVT Ew39AUYk XZ8lEghm4v9qFevYY04NBac7fypoGxY3CRFlXdA+VIoC+1v7bANSgB5boFlqFJumyqFxIupZc/CE5VADkgDMs2xIQQOdCv4NFOYL37hscksRALRrdXfNHNmOG0uNpoEg3m49rRZK6+BCDup1eN+T1nG7mT6M10pY/OctM6M3Mlf26dwelIaGbW7l1zVXd5XBYV8OwUa/jtH9eNsUQyg6INtlGrHg0mfvBFeDamvH42OaPHyj9hqzSW0/+NI3aaSfAeX+HB2qo6j0ptZDSOqNVqGpoXbzJPoV3DuD1MC4PFbkjL+pAV6g+geWvEF99Z6Fcucgccy55yVcuJqdV7Se3d9KL4MxoBAqLsKtvgC3EA/TYrUBqhIf7UBGnS0V2CqCChJL7pGcnOa0452Q6rh7oJgVuCL+e9f/7aSBnlSXiVA9goSI= 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 5/1/25 05:27, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > Allow __GFP_ACCOUNT and __GFP_COMP flags to be specified when calling > alloc_pages_nolock(), since upcoming reentrant alloc_slab_page() needs > to allocate __GFP_COMP pages while BPF infra needs __GFP_ACCOUNT. > > Signed-off-by: Alexei Starovoitov I would rather see __GFP_COMP implied as we don't need any new users of high-order allocations that are not compound, and alloc_pages_nolock() is a new API. IIRC it would be more important in some early version where free_pages_nolock() was different, now it just calls to ___free_pages() which has the tricky code for freeing those non-compound allocations. But still, I'd really recommend that approach. Note __GFP_COMP is simply ignored for order-0 so no need to filter it out. > --- > include/linux/gfp.h | 2 +- > kernel/bpf/syscall.c | 2 +- > mm/page_alloc.c | 8 +++++--- > 3 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index be160e8d8bcb..9afbe5b3aef6 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -354,7 +354,7 @@ static inline struct page *alloc_page_vma_noprof(gfp_t gfp, > } > #define alloc_page_vma(...) alloc_hooks(alloc_page_vma_noprof(__VA_ARGS__)) > > -struct page *alloc_pages_nolock_noprof(int nid, unsigned int order); > +struct page *alloc_pages_nolock_noprof(gfp_t gfp_flags, int nid, unsigned int order); > #define alloc_pages_nolock(...) alloc_hooks(alloc_pages_nolock_noprof(__VA_ARGS__)) > > extern unsigned long get_free_pages_noprof(gfp_t gfp_mask, unsigned int order); > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index d0ddba2a952b..83af8fa9db3f 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -578,7 +578,7 @@ static bool can_alloc_pages(void) > static struct page *__bpf_alloc_page(int nid) > { > if (!can_alloc_pages()) > - return alloc_pages_nolock(nid, 0); > + return alloc_pages_nolock(__GFP_ACCOUNT, nid, 0); > > return alloc_pages_node(nid, > GFP_KERNEL | __GFP_ZERO | __GFP_ACCOUNT > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 1d77a07b0659..303df205ca7d 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -7379,6 +7379,7 @@ static bool __free_unaccepted(struct page *page) > > /** > * alloc_pages_nolock - opportunistic reentrant allocation from any context > + * @gfp_flags: GFP flags. Only __GFP_ACCOUNT, __GFP_COMP allowed. > * @nid: node to allocate from > * @order: allocation order size > * > @@ -7392,7 +7393,7 @@ static bool __free_unaccepted(struct page *page) > * Return: allocated page or NULL on failure. NULL does not mean EBUSY or EAGAIN. > * It means ENOMEM. There is no reason to call it again and expect !NULL. > */ > -struct page *alloc_pages_nolock_noprof(int nid, unsigned int order) > +struct page *alloc_pages_nolock_noprof(gfp_t gfp_flags, int nid, unsigned int order) > { > /* > * Do not specify __GFP_DIRECT_RECLAIM, since direct claim is not allowed. > @@ -7415,11 +7416,12 @@ struct page *alloc_pages_nolock_noprof(int nid, unsigned int order) > * doesn't want to deplete reserves. > */ > gfp_t alloc_gfp = __GFP_NOWARN | __GFP_ZERO | __GFP_NOMEMALLOC > - | __GFP_ACCOUNT; > + | gfp_flags; > unsigned int alloc_flags = ALLOC_TRYLOCK; > struct alloc_context ac = { }; > struct page *page; > > + VM_WARN_ON_ONCE(gfp_flags & ~(__GFP_ACCOUNT | __GFP_COMP)); > /* > * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is > * unsafe in NMI. If spin_trylock() is called from hard IRQ the current > @@ -7462,7 +7464,7 @@ struct page *alloc_pages_nolock_noprof(int nid, unsigned int order) > if (page) > set_page_refcounted(page); > > - if (memcg_kmem_online() && page && > + if (memcg_kmem_online() && page && (gfp_flags & __GFP_ACCOUNT) && > unlikely(__memcg_kmem_charge_page(page, alloc_gfp, order) != 0)) { > free_pages_nolock(page, order); > page = NULL;