From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2EEC3E3C5F for ; Mon, 25 May 2026 08:42:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779698524; cv=none; b=D2KRbi3pOIEuO4syyXadJzKvPXAnP/qyhCMHD/5G2/IdXnsqEoU8lvdwLvQnLXsaXs1HZIfzdfS/+tgO2YV1vOjXm84bSX0SgFRsa1jrdGy3mjmWNjNAqXJ/4AE9AjJCz43h8vpkrN8wVcwIlBcMJvpZfTcIPaxTABCDZG0T+Co= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779698524; c=relaxed/simple; bh=Qaas3Xi9KKGq5oO/yBUGZjifDR7cy0n88kvn4dABAbU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LSN61AwoFn8OnTAgS9SKi1atLgNpP8Fy281TIzKeuo4sf39IJvmYTrV2a0qruy84HLMCvR+XwqpjDc4TdjG5d5kQzAluurMnDbUqKf6Txwutt8LBgsVAkDcg4ljKYxVcrzbgiHjTrfdD042E14KSd5BWdTi0n5UidNutm9SZKZg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=PrNIVoDA; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="PrNIVoDA" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-490388fd0dbso37036535e9.0 for ; Mon, 25 May 2026 01:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779698521; x=1780303321; darn=vger.kernel.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=TGM0HnwsQ+sAC0d9nq1+H2+fQIQXp7hPnnfrzxBYUA0=; b=PrNIVoDAkImcqdNuiIIhPFMjiCTds/Y4G88Q/H5SjAu9vitLCmLwjt56BOPwMEMJTx 8s7o+ttroVkFc+YISD9C/ZWZHYCr88m3kV3pRGcdPpbUn1dJSeeJuFg7gYvJpW40Otgb LOTQfKyNTPtsRKil0Ad+6LhfHC1yco7BwWEaAik/Z9zK88t+nrkh0paoFnmHNveYo7eh aP3NhNS/xVYznX5N4MdU67lnWeR+QPG3T8dFvgmUEdTKsKg5uNZphzbu5DQKSh/iJJ50 mguTfjvc3DNAjuvZ4No8uQFBNIQh6OOOEzU5x9Zn0XtYl8wnOncKtithGK1ul1kPgotU 3GoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779698521; x=1780303321; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TGM0HnwsQ+sAC0d9nq1+H2+fQIQXp7hPnnfrzxBYUA0=; b=tWpdR+UXFv41JEWqURiZzCvo+FoznUs6Mn23GEkbqmVYtmEJmqUWyThyoAKL0YahfM yBidqCddqMF84TB43bWuUx/EncaBUUkbCSg76Gq+9UUeI2y/r+ge4zcVv81fVTtONpGq xzUaOPrWRpg1d5uJ0MrgBYsiokaOuFmeN5cQ0lR20sMt/YZQYwg/QE9CaFYkg+fOL8KV LrzMbot1SkOlSZTcVhk8R6JKtBEgjOIdc/n+p2t59Bsk3Uqas8u2brZsFUDRUTOQnjrL g8Bo6iLbM7MMN2l5OxbGuZdSwkSYuSKy6FG7UZuHYrn8lXxHnM4tnMGLf2npCuR8xb39 5bGA== X-Forwarded-Encrypted: i=1; AFNElJ8LbKsbi6hDeDjSq97ObzTF2JewO1iLayNb5wLS6yT4pzZDX4UBypdDObq9JmENtR6dT34zSG1uUg+GM9M=@vger.kernel.org X-Gm-Message-State: AOJu0YxeUaiUI+zjZ4mP+0vDTbEJNpI3Svj56stVcOcEOG4m+rqJBNNO wy6STPgRDFxFAkX2kYX7iMwko3wpoalNiIq4Ukfbmx2wB3sKL3iF6FrzafuuDLkdB4sdXoXPxKn xZCU9 X-Gm-Gg: Acq92OFNwG7PHzKyFs7NHkNZnYH5USaaCe82G2e7e5qGs8q16S9rzG14niT4R2l5YDT bymwZwk72gDd4XqHvUEHet/MgSB9ThImeznlm7/zMm4VwDaK3pKh1u0yEmn2WfwcWZd3YKUqnDV K0iuqoryEYfFo6VSG/8fzEyAyioHPeXIMpUKF/EtVoCnnPctX8N0gnIb54V2QrSFhZ3NRIMGMRx 1R9AI1nOnSE7tJd1Td98K3XRfHN5MA6ITM746tTti4hvh429Gi+7oIKMuf0m0gcNGiuqmj8wyYq vYqwi1IckmtRrU4cGcvweXdBwdpykkl6vXb4xPG8fOoga68r3Y92bDDN6kqoXzG+kJn7QiEKufB RWFaE0oLWaMwoT23yUlCjPmlJubi2NYgn9TjQEnQKs2rzeaAc54vAjm6/3v5buOU2cjnDlVt87b aVevlgkwV3oXKhP6C/DMo4LXiClpsIRZvHZd3b X-Received: by 2002:a05:600c:6095:b0:490:51b9:2309 with SMTP id 5b1f17b1804b1-49051b924b1mr152029475e9.29.1779698520913; Mon, 25 May 2026 01:42:00 -0700 (PDT) Received: from localhost (109-81-80-247.rct.o2.cz. [109.81.80.247]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490428ee444sm82000815e9.24.2026.05.25.01.41.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 01:42:00 -0700 (PDT) Date: Mon, 25 May 2026 10:41:58 +0200 From: Michal Hocko To: Waiman Long Cc: Marc Zyngier , Thomas Gleixner , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH 1/2] gfp_types: Introduce a new GFP_ATOMIC_RT gfp flag Message-ID: References: <20260520204628.933654-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260520204628.933654-1-longman@redhat.com> On Wed 20-05-26 16:46:27, Waiman Long wrote: > The GFP_ATOMIC flag is to be used in atomic context where user cannot > sleep and need the allocation to succeed. However, it does not support > contexts where preemption or interrupt is disabled under PREEMPT_RT > like raw_spin_lock_irqsave() or plain preempt_disable(). > > With the advance of the ALLOC_TRYLOCK allocation flag in the v7.1 > kernel, it is possible to allocate memory under such contexts by using > spin_trylock to acquire the spinlock in the memory allocation path. This > does increase the chance that the allocation can fail due to the presence > of concurrent memory allocation requests. So its users must be able to > handle such memory allocation failure gracefully. > > The ALLOC_TRYLOCK flag will only be enabled if none of the > ___GFP_DIRECT_RECLAIM and ___GFP_KSWAPD_RECLAIM flags are set. > > Introduce a new GFP_ATOMIC_RT gfp flag for those PREEMPT_RT > atomic contexts. This new flag will fall back to GFP_ATOMIC in > non-PREEMPT_RT kernel. GFP_ATOMIC can continue to be used in contexts > where preemption and interrupt are not disabled in PREEMPT_RT kernel > like spin_lock_irqsave(). Before we go this way we need to really be clear we do want to support raw_spinlock (aka RT) contexts. This is a big commitment because it dictates internal allocator locking that would have potentially a much bigger impact long term. I would go this way only after/when we conclude there is absolutely no other way and we need to have allocator in those critical sections. Now you have a single place which complains ATM without much of an explanation why this cannot be really handled in other way. Have you even considered any options to pull the allocation from within the raw spin lock section? -- Michal Hocko SUSE Labs