From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
	(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 12A7E3806C2
	for <linux-kernel@vger.kernel.org>; Tue, 18 Aug 2026 23:59:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1787097581; cv=none; b=PPlRVm/oH1EWML8dnfmWSqYesbHZjiNAuU0IfycIh7kjM4newg6CCl+ncuddfyokw/22DaxLAy9WRWU2kRqgJVOtUyll8G/YG9COGASNI2BcLnTawid9mVToUznokzItU5PVvtv8mS2a49naOcDVzjkIHbJ6et+nMZ6ntn5p3lI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1787097581; c=relaxed/simple;
	bh=tdJJBQS5GkBD08q8cqFRsGQQTGP+W6fqUTDbkPVNFTk=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=apWcOFLWGU8Y58QX1EhU96aYfYMMNLSrcr+Z+cnHINAVd2qr3x4E0GwLrZSEnRQOQC7px5IqGC5hD0BhYiGTZae0UuFd9eGHhDtSQ3NSo1Ic3IosVQP1RiecA23inFtbue2FY72FXsbgRe7jysrXblJoBqrnqZVltaqRLNDQZNA=
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=O0SVV/r9; arc=none smtp.client-ip=100.103.45.18
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="O0SVV/r9"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3563C1F00A3A;
	Tue, 18 Aug 2026 23:59:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1787097579;
	bh=kz5005IQhYTqHLRDhRzDxqDrp+d9vWEqAIEu8aMS/Vg=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=O0SVV/r9mWdAdFT+WVyA28j6wwk6fspX0dtkmaeApzEcqzQRivbjuJsZjEurJYhf1
	 ovi1kSEwM+d9qUxORYLTlzqA8w6COo9u2e2MPPqME6P5BQlzPe5eBZxbblYrQqzjg0
	 jhr31UhobOqi7JhSkAtPwvuiQmCTM0X+VXiAEJBA=
Date: Tue, 18 Aug 2026 16:59:38 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Lance Yang <lance.yang@linux.dev>, david@kernel.org, mhocko@suse.com,
 leon.hwang@linux.dev, linux-mm@kvack.org, muchun.song@linux.dev,
 osalvador@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range()
Message-Id: <20260818165938.243ead051f792ee1519a5c79@linux-foundation.org>
In-Reply-To: <aoTuwV76Sd0ahBEC@casper.infradead.org>
References: <20260818115526.654d7311366b66cd031c67e4@linux-foundation.org>
	<20260818221858.86452-1-lance.yang@linux.dev>
	<20260818162430.0a51522ac9bd671cce62650f@linux-foundation.org>
	<aoTuwV76Sd0ahBEC@casper.infradead.org>
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: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 19 Aug 2026 00:46:09 +0100 Matthew Wilcox <willy@infradead.org> wrote:

> On Tue, Aug 18, 2026 at 04:24:30PM -0700, Andrew Morton wrote:
> > On Wed, 19 Aug 2026 06:18:58 +0800 Lance Yang <lance.yang@linux.dev> wrote:
> > 
> > > >> > 
> > > >> > That's pretty bad behavior and we might want to fix it in earlier
> > > >> > kernels.  Is PREEMPT_NONE effectively dead in 6.18.x and its
> > > >> > existing users?
> > > >> > 
> > > >> > If yes, we do want to fix older kernels then we should merge this.
> > > >> > 
> > > >> 
> > > >> Okay, but that would be stable-only fixes?
> > > >
> > > >Not understanding.
> > > >
> > > >Maybe you refer to adding a patch to -stable but not to -linus?  That's
> > > >against the -stable rules
> > > >(Documentation/process/stable-kernel-rules.rst).
> > > 
> > > Since cond_resched() is a scheduling no-op under LAZY/FULL anyway (only
> > > the __might_resched() debug check remains), why not take this upstream
> > > with Cc: stable?
> > 
> > I think so - as long as PREEPMT_NONE exists we should support it as
> > well as we can.  If the day comes that PREEMPT_NONE is removed, then we
> > get to remove lots of cond_resched()s.  mm/ has 200 of the things.
> > 
> > > Mainline scheduling stays unchanged, and stable can pick it up for old
> > > PREEMPT_NONE kernels. wdyt?
> > 
> > Addressing this issue in older kernels is another reason.
> 
> That is not the direction that the scheduler developers wish us to take.

Well back luck.

"Packet receive timeouts were traced to sparse HugeTLB unmapping in
production".  Do sched developers have a proposal to fix that in
year-old kernels?