From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 7A1B738B7D9 for ; Thu, 7 May 2026 12:33:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778157224; cv=none; b=oIrsg1YX2GN4qCSSCTMyl6PKaleolCfFbTqm8LuzUdyguKsdGPRsQPwXfPNrto8sCSEdrELyztCaM71LmWrsgb7XdOx0inOz6ajas9rUGyncmrcB4qQ157d+vYes/TJabtiesfSi5mEha1bfN+FT5JrMx+ytqUei9vQXXReQcCI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778157224; c=relaxed/simple; bh=/j34EO3N1sgNWbbycnNE9oIkrmRtDeYAbWJpqtqpUyE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rxCkFdAi4QMxwdBPj4ImLR+ZQCj8+1F7IPep3ukofbZ/b10yAn0ewabsMUfk1vl/7ebTYIB3hKl6wxpEM0wuL/cy0d7b/sulZHyo7Hmu01TceDti+SfLKCo42Ggb6UfgAoyFNXFblhQ3o64Eg6zonMW2yPqMFvX+YsS5cO0+T8M= 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=TvSLHeQh; arc=none smtp.client-ip=209.85.128.50 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="TvSLHeQh" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488b0e1b870so11689735e9.2 for ; Thu, 07 May 2026 05:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1778157221; x=1778762021; 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=CTmqfglj2+4OL7BNewSjF7y+lLfP01LseLD6DRMfrg8=; b=TvSLHeQh1k8RDtc4m0RGSncIIA4+AB7xI/VNLFX32VRLO9irVp3fZUAw7NxYaSckYs 5QFjvS2RM93n9KICHemXIbAg4nDnMB7LNKCVxrtXXPseCaRiPZlpZDX/yADKEimpULhm ZqhfEfnvfieojZpKoyad5Pt6bcywpDEYRjPGJziwGCO/A1IbEDPJE77W1xBESXrCCiLh 8pOL/O9it9uuL9SzWvJDiN+Xyps9/ghEvrcFY4L8WnHcw5FDr8IIBT4wnCtvnWVXeHJ0 iJcGsd7EhfDHdCayfA44eEy3zKxPRtxUrFC3BRfnrqI61kmLJpZxwMRuclHrt60GU8Df RNaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778157221; x=1778762021; 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=CTmqfglj2+4OL7BNewSjF7y+lLfP01LseLD6DRMfrg8=; b=Tch0sRu9szOzsQdUKRk85jm2/gLbLiBP0GG78D11qe2Lvz7JIPGMcwIwgmYkANZkdQ RanDyYr1pxo2Mqu/KNdAppuaA95YGIg1ngYE4w9gSR65lfbCLiU2eiVckP9UOk+mVA8E He8PxBeDpb4ozK91CTIp3KlB3vaK/eHMfSzP20X3c/Y1/qcxtJpH0e3WqZQfMhdJaFJ/ S6oYbBeRMeFmZH2cgZINw/DZ5Yzzl7DxdvxpIom4e357DTzjxxNlcMJyAY8pn78EBffU tcLWyqLIxRySmkxIH1E78dtks7od+sy9vK6w1dDatN7chbwW1Bkht0Z1dmeAmBsKGoDM iYtg== X-Forwarded-Encrypted: i=1; AFNElJ+tgK9AMyd+ENqNKJ+dBuSCRngvnWnX9iXXBJ79l11pfH+G8I9aR9fcHQfgCA4PQVPGoWV88K7JVZ/WovY=@vger.kernel.org X-Gm-Message-State: AOJu0Yx3k7K4gj8BfYOZguUPE7rtj3eqKdicUMziKURI6XYaMzSuXHlF 5PXFtYnR+8F+0fOvr/zBV2oSlYE8rNH6deZwL16NYNHdC/H+EKv9HsVmw8QITN0N0Ig= X-Gm-Gg: AeBDieutD+I9A+WneJcqGIILqEYBsgUg5r8q9jeoWsaBz/dDwKZO5HonAgTmicVerVJ 3LrrnSYACy1s/X2pfvXpj5RQm156EWpxWdvR2iHmLQ3Zg5LP0Roj5fXFdJiUQa5sOuqD1jKhkSA DbGWD6a9fE7NfHYkvkLh1xlCXOqU3t3ko34zxpIirSNX4r0BOjAJ0PQ6cqMFQuNsaHOwXTWmLwA o6W/VcpKRQhP9AqGTcB/ZXUlFn9w+h/iXB4LR/gQaVaQ4UhQbexfXzhiokmZvrr45PFh3R679aq emAvkMrio6/xADYK+cgL6rCu/NdNnemGiaYVUjdbc7uwoKN2VEmGcCbZs+D7NDoXqzTwvUq3OzB H2k6UKJ1tz+TY6JiWQ8cwl4SYTW7+4hXb10DoTEEzAK6A4imBsVLcAnzZRmwhg/TiXB5i9ETDZi GnbgS78SRc2CMk5jR5qZjNaXp25L+Tw+CdHnjETlvJ5BXEAfdtTn6Q9brxGGA= X-Received: by 2002:a05:600c:4c25:b0:48a:65a5:750f with SMTP id 5b1f17b1804b1-48e51f46ddamr76036625e9.21.1778157220675; Thu, 07 May 2026 05:33:40 -0700 (PDT) Received: from localhost.localdomain (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e5390f854sm117995255e9.14.2026.05.07.05.33.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2026 05:33:39 -0700 (PDT) Date: Thu, 7 May 2026 14:33:37 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Chen Wandun Cc: longman@redhat.com, chenridong@huaweicloud.com, tj@kernel.org, hannes@cmpxchg.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cgroup/cpuset: move PF_EXITING check before __GFP_HARDWALL in cpuset_current_node_allowed() Message-ID: References: <20260507105434.3266234-1-chenwandun@lixiang.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3chgs2uacfweczqc" Content-Disposition: inline In-Reply-To: <20260507105434.3266234-1-chenwandun@lixiang.com> --3chgs2uacfweczqc Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] cgroup/cpuset: move PF_EXITING check before __GFP_HARDWALL in cpuset_current_node_allowed() MIME-Version: 1.0 On Thu, May 07, 2026 at 06:54:34PM +0800, Chen Wandun wrote: > This makes it unreachable in the common case, so dying tasks can get > stuck in direct reclaim or even trigger OOM while trying to exit, > despite being allowed to allocate from any node. (OTOH, the caused OOM could select this task and bypass the hardwall. So this should only expedite but no unblock the exit path.) > Move the PF_EXITING check before __GFP_HARDWALL so that dying tasks > can allocate memory from any node to exit quickly, even when cpusets > are enabled. This makes sense to me on its own (given other hardwall exemptions, namely the commit c596d9f320aaf ("cpusets: allow TIF_MEMDIE threads to allocate anywhere")). Acked-by: Michal Koutn=FD At first, I wondered whether this could happen on cpuset v2 -- it can -- because only per-cpuset hardwalling is absent but the generic logic for GFP_USER allocations is still meant to be in place. Nevertheless, it occured to me we can spare callback_lock in this function (a separate chaneg for cpuset_current_node_allowed()): --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -4213,6 +4213,9 @@ bool cpuset_current_node_allowed(int node, gfp_t gfp_= mask) if (current->flags & PF_EXITING) /* Let dying task have memory */ return true; + if (is_in_v2_mode()) + return true; + /* Not hardwall and node outside mems_allowed: scan up cpusets */ spin_lock_irqsave(&callback_lock, flags); Regards, Michal --3chgs2uacfweczqc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJEEABYKADkWIQRCE24Fn/AcRjnLivR+PQLnlNv4CAUCafyGnBsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQfj0C55Tb+AisYgEA2XwE8BxodpT847kFKFjP 5wujFu0d2aAwT/mq1EROxS4BAPD2z9mAVnY5ofEnOUjFsXuHoFYi/Uc5AW/BoRKX GLUH =9ABV -----END PGP SIGNATURE----- --3chgs2uacfweczqc--