From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BD74338932 for ; Mon, 1 Dec 2025 17:41:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764610873; cv=none; b=fqnf2qDAf+VriZ8KTmFlwrCfn0fFTdYcUR/M9nqK1/SdxIis8hBn6G1hUgWXrp+IKEB+S9JHqOBrfyIrJhCWSdOFXZ6oLQHCJOgIcjIT491UsJCU+b65DU+5MAq1Fq5xud5i079NsOUEa3l52+yLRup47C7N4aXYRzvRoewczFg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764610873; c=relaxed/simple; bh=Sj6mhjQMzdwHKohiqgVdzGZP3an7t4iAYfJ+mIr3XpE=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=ow3tdUeHYLOg8KYYaLLri1iG7so/oBUSC8A1XKyR6aEkF8J2tn9fmvbclJo/UMRJ3W+iP6qIEl5NM7sCvwMaaugXWTjk4EEd2ApDUpJs5nQajrakS1GX2Vs6429ZFF9pHVyauYq51gjqkfM5HbmSU1iNq/RaDae0n1+FoTk0/qU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=hTXvdYEb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hTXvdYEb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D21F3C4CEF1; Mon, 1 Dec 2025 17:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1764610873; bh=Sj6mhjQMzdwHKohiqgVdzGZP3an7t4iAYfJ+mIr3XpE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hTXvdYEb6i/unmZrz+Rf7slgVrzPYVDGF0B6e9pL8HGKiYrUK4oLodn7rYTnZUUWO xfe44vZiPh58gel/gFsPkTUSSF3287dOY2wa5yYEqpGe/1sh4gSUN6VPBECc5IkX5m A+YXc7eAAHUctuek6mq/uUkvvRk++tbC0XyDNBp0= Date: Mon, 1 Dec 2025 09:41:12 -0800 From: Andrew Morton To: Aboorva Devarajan Cc: vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free Message-Id: <20251201094112.07eb1e588b6da2ee70c4641d@linux-foundation.org> In-Reply-To: <20251201060009.1420792-1-aboorvad@linux.ibm.com> References: <20251201060009.1420792-1-aboorvad@linux.ibm.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Mon, 1 Dec 2025 11:30:09 +0530 Aboorva Devarajan wrote: > When page isolation loops indefinitely during memory offline, reading > /proc/sys/vm/percpu_pagelist_high_fraction blocks on pcp_batch_high_lock, > causing hung task warnings. That's pretty bad behavior. I wonder if there are other problems which can be caused by this lengthy hold time. It would be better to address the lengthy hold time rather that having to work around it in one impacted site. > Make procfs reads lock-free since percpu_pagelist_high_fraction is a simple > integer with naturally atomic reads, writers still serialize via the mutex. > > This prevents hung task warnings when reading the procfs file during > long-running memory offline operations. > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -6611,11 +6611,14 @@ static int percpu_pagelist_high_fraction_sysctl_handler(const struct ctl_table * > int old_percpu_pagelist_high_fraction; > int ret; > > + if (!write) > + return proc_dointvec_minmax(table, write, buffer, length, ppos); > + > mutex_lock(&pcp_batch_high_lock); > old_percpu_pagelist_high_fraction = percpu_pagelist_high_fraction; > > ret = proc_dointvec_minmax(table, write, buffer, length, ppos); > - if (!write || ret < 0) > + if (ret < 0) > goto out; > > /* Sanity checking to avoid pcp imbalance */ That being said, I'll grab the patch and shall put a cc:stable on it, see what people think about this hold-time issue.