[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241211034348.GA2091455@google.com>
Date: Wed, 11 Dec 2024 12:43:48 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] zram: cond_resched() in writeback loop
On (24/12/10 16:54), Andrew Morton wrote:
> > Writeback loop can run for quite a while (depending on
> > wb device performance, compression algorithm and the
> > number of entries we writeback), so we need to do
> > cond_resched() there, similarly to what we do in
> > recompress loop.
> >
> > ...
> >
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -889,6 +889,8 @@ static ssize_t writeback_store(struct device *dev,
> > next:
> > zram_slot_unlock(zram, index);
> > release_pp_slot(zram, pps);
> > +
> > + cond_resched();
> > }
> >
> > if (blk_idx)
>
> Should this be treated as a hotfix? With a -stable backport?
>
> If so, we'd need to explain our reasoning in the changelog. "Fixes a
> watchdog lockup splat when running <workload>". And a Fixes: would be
> nice if appropriate.
Good point. This fixes commit from 2018, I guess no one runs writebacks
on preempt-none systems, but I don't see why this should be in -stable.
I'll send updated patch in a bit.
Powered by blists - more mailing lists