From: Michal Hocko <mhocko@suse.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Leon Hwang <leon.hwang@linux.dev>,
linux-mm@kvack.org, Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
linux-kernel@vger.kernel.org, Lance Yang <lance.yang@linux.dev>
Subject: Re: [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range()
Date: Wed, 19 Aug 2026 10:59:15 +0200 [thread overview]
Message-ID: <aoVwY4d2Un5Fny7e@tiehlicka> (raw)
In-Reply-To: <68cb43c6-6ed2-488f-916a-b22bb956adcf@kernel.org>
On Wed 19-08-26 10:54:11, David Hildenbrand wrote:
> On 8/19/26 10:50, Michal Hocko wrote:
> > On Wed 19-08-26 09:53:25, David Hildenbrand wrote:
> >> On 8/18/26 20:55, Andrew Morton wrote:
> >>>
> >>>
> >>> 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).
> >>
> >> It's tricky: if a problem only exists in stable (there is nothing to fix in
> >> Linus' tree), then a stable-only fix is acceptable.
> >
> > The crucial quiestion is whether this is something that needs a code fix
> > or a configuration fix. Really fighting for low latencies with
> > PREEMPT_NONE is a kinda lost battle. You might want to play whack a
> > mole...
>
> Yes, I read your comment on the other thread afterwards and I agree.
>
> The whole reason we added cond_resched() all over the place over the years was
> to avoid splats from false detected hung tasks (e.g., 30s ...).
>
> Not to optimize latency in the ms range.
Exactly, they aimed to provide reasonable upper boundary of
no-preemption with non-preemptive scheduling. And those are on decline
which is a reason to keep bar for adding new ones high and also
optimizing low latencies fundamentally makes no sense for those models.
So even more reason to not add them in these cases. This will just add
more future work when non-preemptive models are gone which will
eventually happen AFAIU.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2026-08-19 9:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 13:50 [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range() Leon Hwang
2026-08-18 14:23 ` David Hildenbrand (Arm)
2026-08-18 18:17 ` Andrew Morton
2026-08-18 18:21 ` David Hildenbrand (Arm)
2026-08-18 18:55 ` Andrew Morton
2026-08-18 22:18 ` Lance Yang
2026-08-18 23:24 ` Andrew Morton
2026-08-18 23:46 ` Matthew Wilcox
2026-08-18 23:59 ` Andrew Morton
2026-08-19 6:55 ` Michal Hocko
2026-08-19 7:53 ` David Hildenbrand (Arm)
2026-08-19 8:50 ` Michal Hocko
2026-08-19 8:54 ` David Hildenbrand (Arm)
2026-08-19 8:59 ` Michal Hocko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoVwY4d2Un5Fny7e@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=lance.yang@linux.dev \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox