suspending threads before devices

Konstantin Belousov kostikbel at gmail.com
Wed Nov 19 10:16:10 UTC 2014


On Tue, Nov 18, 2014 at 05:21:56PM -0500, John Baldwin wrote:
> I would certainly like a way to quiesce threads before entering the
> real suspend path. I would also like to cleanly unmount filesystems
> during suspend as well and the thread issue is a prerequisite for
> that. However, reusing "stop at boundary" may not be quite correct
> because you probably don't want to block suspend because you have an
> NFS request that is retrying due to a down NFS server. For NFS I think
> you want any threads asleep to just not get a chance to run again
> until after resume completes.

It was already correctly described why unmount is not an option at suspend.
We could consider suspending filesystems, but if usermode threads are
going to be stopped, it makes no sense.  Just syncing filesystems,
as in VFS_SYNC(), should be enough.

WRT TFD_SBDRY, I do not think that we should enforce stopping at usermode
boundary for the suspend.  VFCF_SBDRY prevents lock cascade on the live
system, there is cannot be more stopped threads for whole-system suspension.
I.e., the global thread stopping should ignore the TDF_BOUNDARY flag.


More information about the freebsd-arch mailing list