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 4D375E7717F for ; Tue, 10 Dec 2024 09:05:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D20DD6B0117; Tue, 10 Dec 2024 04:05:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD0FB6B0118; Tue, 10 Dec 2024 04:05:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B71256B0119; Tue, 10 Dec 2024 04:05:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 89C686B0117 for ; Tue, 10 Dec 2024 04:05:27 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 398F6C05B3 for ; Tue, 10 Dec 2024 09:05:27 +0000 (UTC) X-FDA: 82878465390.05.2314F0E Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by imf29.hostedemail.com (Postfix) with ESMTP id D4FB4120015 for ; Tue, 10 Dec 2024 09:04:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=WHh66fFn; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733821505; a=rsa-sha256; cv=none; b=iEdl4hKnx792lN+P+f3OCwNzQ9Bl9s3V/Np3yzczkXVAy33biVRDLChIrKm5eVrt8l6tCi lo69UUuTbmcAzXqttorKR02jkJOhFJapLnY631V1Ry41T1KRglvDMbaHLJ1CEIlme3PXVI KnzLJ3+o5UG906FGFSsfyzniBM7Pq94= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=WHh66fFn; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733821505; 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=wSWf57S3pNx/JU1MiKz6Yk8eQ8jvmeUXwiP4HDO3kQM=; b=XVsgwG7DBbnPABlNIjE5V7YVP/gm0XkDtwPaKySeOHRAWXm7+6mFH68hleE79qUjGcrNiE SQQvmxJwi3tI63AAMaPlN7eWxEGxfyRHgDVjB5sIBP/1qPEtFXgEGRmPbHh/1yx0wYSbTg PrrNd8eEvDWjr5v9k5t2DJ00yM4sX78= Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-434f09d18e2so28365495e9.0 for ; Tue, 10 Dec 2024 01:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733821524; x=1734426324; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=wSWf57S3pNx/JU1MiKz6Yk8eQ8jvmeUXwiP4HDO3kQM=; b=WHh66fFnBOim9gTe3N/UbODZR9CAXuliI7O032db6u+wIo6MAd7Ok6IloHDojwTGwp QbtSnPoXFOrRGZK6wdZ4H/HUSPZSk0pxgvcdqiq84K1/VGI1Yv6ua+MGycvE4bQu2vgP XVLD6ZRN4EaFnpITbV+cJPY0SXwjdZei/Y6UFrBx7wCA01Z1s4ZlzF+1gjMzA+D/fWDd AnYJpzFcN65onV+mufY9RikCGjHzzKwj6zCf1iCVptw9d7YfkMhYCgomurv+xrCTlyB1 /Wh8cZFJ4Aws21ygLEDsGGzaKLPM0Em4CsPafUAEcH9+yAx8uSmyaQIjbfNmNs2Z7gAW TgeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733821524; x=1734426324; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wSWf57S3pNx/JU1MiKz6Yk8eQ8jvmeUXwiP4HDO3kQM=; b=USbf8dmp5dU3unNXHA0JktWYHpFf4eh4eoDXpSabHmy7E2S/TZ05pRE4tfD3vW+znQ 8ekCHH8YZqUtzLhgOVnVbVPyHgR9pHvYe0/lDgtdbl1oDg9pJK97pAfgQuRcVXMPI2+Z jvK+ZgKr0Ppamo+M4yQYK7Cd6wEKjfOy1+pJgabqfqi2rVGuzt0zzwpZgDBKVE1eII2h /lK13RPbvNLunqCsX1LJM3ZG2JdBTlnk/9JLaG9132lla3q9akwDsuuTFVuQEW5ZLxz3 r6zT35wsd1svZKzo8QLFksbpL3c1urPijDExyt+uqCHLc/qRUaIvzPYHsMgMefWRmvVa JRYA== X-Forwarded-Encrypted: i=1; AJvYcCU0mygMji6u+4wUEZJmS/8kFB+eZ0lfxF3Rdw14mS3fg3oTjt3D/ngeOi4EJqxy0dXm2QivAkfENw==@kvack.org X-Gm-Message-State: AOJu0Yxo+UG3Qx7kVBG4DiPFn51ald7ym2iZQFRowq89thbFxyLqDxb9 qFxfrnnXCIeh8jDDl3Xb8pzhnC/Oj1KZmHgU5xYOVCYhDesNBa+3oBagNpaFAdj6n/NUsSTIlYc r X-Gm-Gg: ASbGncs8Bxfxg8+i7y4ZRCkvhzyIFwNN3vlceQYGSV/xXQChGAwlUHaP1o8kOuVPt+/ iMqqJdBMHN2ZvpEjboulq89rVG+ri1Srh72Qef92Un0pIA0NsY8uMBjT7Z82tA3TdWquS/BDIS/ HYtFYEEKHt8PfRGMdLIrtmaIIyCu8nCgSRp0mczTSkW+uHcGjcan++1Rv12IfuSV/9OqwRCUJQp kEY5EwgAoNqyRTdNDdQf6CzVUU8MAq6o9d530YtYEILFcawg2qUJN+rf2KCNPAfJYA= X-Google-Smtp-Source: AGHT+IF2iKP0yVCjz96JB1POvOOwu3Kr/+2xWFzVMMQtlBZ+Vt7KGeprjZJWL+m+4hqQSdJVSQqriQ== X-Received: by 2002:a7b:cc90:0:b0:434:ea21:e152 with SMTP id 5b1f17b1804b1-434ea21e3b2mr83111495e9.5.1733821523820; Tue, 10 Dec 2024 01:05:23 -0800 (PST) Received: from localhost (109-81-86-131.rct.o2.cz. [109.81.86.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434e8ec8072sm114404685e9.18.2024.12.10.01.05.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Dec 2024 01:05:23 -0800 (PST) Date: Tue, 10 Dec 2024 10:05:22 +0100 From: Michal Hocko To: Alexei Starovoitov , Matthew Wilcox Cc: bpf@vger.kernel.org, andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org, peterz@infradead.org, vbabka@suse.cz, bigeasy@linutronix.de, rostedt@goodmis.org, houtao1@huawei.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, tglx@linutronix.de, tj@kernel.org, linux-mm@kvack.org, kernel-team@fb.com Subject: Re: [PATCH bpf-next v2 1/6] mm, bpf: Introduce __GFP_TRYLOCK for opportunistic page allocation Message-ID: References: <20241210023936.46871-1-alexei.starovoitov@gmail.com> <20241210023936.46871-2-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: cojn6neudokinzb5q5jxiymmewgr6sxo X-Rspam-User: X-Rspamd-Queue-Id: D4FB4120015 X-Rspamd-Server: rspam08 X-HE-Tag: 1733821494-247234 X-HE-Meta: U2FsdGVkX1/R3fYkc22zCWNAXvOhKabEJPDBS3Bgyg1L79tHpW0k5CBfGM+O21Wq8vys+5gAWCxpg6phngePJ4YxX4dRmLkkm3g12Kymj71ESmWOjdjSNy2meeb/Vnfv2jYOUD2pQVYuUaoQ3qsjpxyHNYoq4Ch+d2c0ddiSJk9tGlyRlT32+jOfb6PTFf+w73yYX+VF9HiE6eATkUb0y+CaGHv0qk5Yqdg2AuInHZ6ZS7UjuIqvLW8d90WdXTMg1KRt4iAT1blR4DRizpfkP0PwY2HODhxickQQ2MCEWTAZRZbeOpJnmqi/3isA4XTLYRAmpdgU2O6BvBctlnjbJk7p0mzlftDLTRxd/H5P6GUqsreco6RzIoZOG0zjpTCQ9/A99XqpnKVltY7xv3xUHyt8tUEFqvW99y5iZT0ciTMsA0+8ol5tpiKTDxJX54ZEIytpaMjhXGposgyl6cHdY+6xhledXdIsuetcSdw65s6wE4KO1IFNGyA4WZMCzfGaATf7Orn5yotMq5EFj4rS0at5CoIjcvNbHzPYxMN7KB2vvM7Z4Ff1MMO/pEeaPsYUZdkYtX+Gb47+bCArr/CM1iTyXuvIj7Y++YsmFF48hEtLRTnW7kcmKR0T4OeV0d5/2OQ4WW3F/lyjUmptv09CdIBFszMBeJWwlK/XCuBehsK3EymZWwjE+tyNkrNACv3Cl/3b5QmteVxtWzqvE0Dz0eDEIP726Vm1yNiSqaHYsULH/XLj+8WZIuIw8hVuGNb/6wJtk3QV5zE0kLXHPYKvoJTHSXTRDW7iKxToYRVxKhp53wjASxURzoeHv/A6p43+mkwa9yT2pYLiggcNJzoVMnP++JZp+Nq7w3MP+xBzrmFR/ld4bWsL/w4h70yBJO4hWKHhR02Efx4Cnf0GE695QJqWyMK65Hx7KnZCoNByPZWVjL2TVNIJEpti5xOFxyK1opJz6RVppJTMKMlhlns m8dlQSzT yvGahepYeu51Q/x4JZWp+CxMm+51A0/uDhEv91F9pXLMOdiQheDagehuuxKZU5CU6vPE2+baxduyl2BijZ2EGakvqCl7ao3hJIwbESQkkTpeK5s81KTOsAxXYsaVbMOevz/mUf36X7i2dohlwvgF9+FiyuvUSqdY6pIjsc6sz8OR4IQJMzHyNptqasPzGQ1jukuojO2vyL13LBoAKHs51huofRp6pDvwS7GdIqtEDCAHdwo4eGRwwu25zaIa+n1IvBpnmUPNGw1D6sTm2p4ODiI3NYxY3iIoCXJbHm8Mb+qzJ7NQS5tUwRTVXbJG+UJd8I0JJrOCRlRCOB3FdIkKT7K9fxejzNwHBEsFpn+1lsxjFG5OjDzX+QyL5KhzB8uCV2RNsWXS2qd9bdwaTqJ92WE9bd7ZEPALA9YHLUiDXHpt9JngnNuHVOZRL3Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.070091, 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 Tue 10-12-24 05:31:30, Matthew Wilcox wrote: > On Mon, Dec 09, 2024 at 06:39:31PM -0800, Alexei Starovoitov wrote: > > + if (preemptible() && !rcu_preempt_depth()) > > + return alloc_pages_node_noprof(nid, > > + GFP_NOWAIT | __GFP_ZERO, > > + order); > > + return alloc_pages_node_noprof(nid, > > + __GFP_TRYLOCK | __GFP_NOWARN | __GFP_ZERO, > > + order); > > [...] > > > @@ -4009,7 +4018,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask, unsigned int order) > > * set both ALLOC_NON_BLOCK and ALLOC_MIN_RESERVE(__GFP_HIGH). > > */ > > alloc_flags |= (__force int) > > - (gfp_mask & (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)); > > + (gfp_mask & (__GFP_HIGH | __GFP_KSWAPD_RECLAIM | __GFP_TRYLOCK)); > > It's not quite clear to me that we need __GFP_TRYLOCK to implement this. > I was originally wondering if this wasn't a memalloc_nolock_save() / > memalloc_nolock_restore() situation (akin to memalloc_nofs_save/restore), > but I wonder if we can simply do: > > if (!preemptible() || rcu_preempt_depth()) > alloc_flags |= ALLOC_TRYLOCK; preemptible is unusable without CONFIG_PREEMPT_COUNT but I do agree that __GFP_TRYLOCK is not really a preferred way to go forward. For 3 reasons. First I do not really like the name as it tells what it does rather than how it should be used. This is a general pattern of many gfp flags unfotrunatelly and historically it has turned out error prone. If a gfp flag is really needed then something like __GFP_ANY_CONTEXT should be used. If the current implementation requires to use try_lock for zone->lock or other changes is not an implementation detail but the user should have a clear understanding that allocation is allowed from any context (NMI, IRQ or otherwise atomic contexts). Is there any reason why GFP_ATOMIC cannot be extended to support new contexts? This allocation mode is already documented to be usable from atomic contexts except from NMI and raw_spinlocks. But is it feasible to extend the current implementation to use only trylock on zone->lock if called from in_nmi() to reduce unexpected failures on contention for existing users? Third, do we even want such a strong guarantee in the generic page allocator path and make it even more complex and harder to maintain? We already have a precence in form of __alloc_pages_bulk which is a special case allocator mode living outside of the page allocator path. It seems that it covers most of your requirements except the fallback to the regular allocation path AFAICS. Is this something you could piggy back on? -- Michal Hocko SUSE Labs