On Tue, Oct 03, 2017 at 11:15:07PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> > On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > > Now that all filesystems which used to rely on kthread
> > > freezing have been converted to filesystem freeze/thawing
> > > we can remove the kernel kthread freezer.
> > >
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxxxx>
> >
> > I like this one. :-)
>
> However, suspend_freeze/thaw_processes() require some more work.
>
> In particular, the freezing of workqueues is being removed here
> without a replacement.
Hrm, where do you see that? freeze_workqueues_busy() is still called on
try_to_freeze_tasks(). Likewise thaw_processes() also calls thaw_workqueues().
I did forget to nuke pm_nosig_freezing though.
Also as I have noted a few times now we have yet to determine if we can remove
all freezer calls on kthreads without causing a regression. Granted I'm being
overly careful here, I still would not be surprised to learn about a stupid use
case where this will be hard to remove now.
Only once this is done should this patch be considered. This will take time. So
I'd like more general consensus on long term approach:
1) first address each fs to use its freezer calls on susend/hibernate / and thaw
on resume. While at it, remove freezer API calls on their respective
kthreads.
2) In parallel address removing freezer API calls on non-IO kthreads, these
should be trivial, but who knows what surprises lurk here
3) Lookup for kthreads which seem to generate IO -- address / review if
removal of the freezer API can be done somehow with a quescing. This
is currently for example being done on SCSI / md.
4) Only after all the above is done should we consider this patch or some
form of it.
Luis
