Date: Wed, 19 Nov 2014 12:16:05 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Jung-uk Kim <jkim@freebsd.org>, Andriy Gapon <avg@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: suspending threads before devices Message-ID: <20141119101605.GB17068@kib.kiev.ua> In-Reply-To: <201411181721.56505.jhb@freebsd.org> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> <201411181721.56505.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141119101605.GB17068>