[PATCH v5] kexec: keep the next kernel off hardware-poisoned pages
Rik van Riel
riel at surriel.com
Tue Aug 11 07:51:18 PDT 2026
On Tue, 2026-08-11 at 15:21 +0100, Kiryl Shutsemau wrote:
> On Tue, Aug 11, 2026 at 04:34:02PM +0300, Mike Rapoport wrote:
> > On Tue, Aug 11, 2026 at 04:17:41AM -0700, Breno Leitao wrote:
> > > > >
> > > But I honestly don't have a strong opinion here, though, happy to
> > > batch
> > > it if you prefer. Would this one look better?:
> > >
> > > if (!(pfn % MAX_ORDER_NR_PAGES))
> > > cond_resched();
> >
> > Can't say I know the magic number here, but I think it's better to
> > batch.
>
> Hm. I thought cond_resched() deal with this internally, no?
>
> We call it in pretty tight loops, like clear_contig_highpages() or
> copy_folio_from_user().
>
> I think adding external batching might be a bad move.
>
cond_resched() should be really cheap, indeed.
It gets compiled out completely with PREEMPT_LAZY
or PREEMPT_FULL.
--
All Rights Reversed.
More information about the kexec
mailing list