From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 19:21:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F891E32; Wed, 19 Nov 2014 19:21:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 746BD77F; Wed, 19 Nov 2014 19:21:17 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B32C1B93C; Wed, 19 Nov 2014 14:21:15 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: suspending threads before devices Date: Wed, 19 Nov 2014 14:08:20 -0500 Message-ID: <1580793.3ynJAbfVom@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <201411181721.56505.jhb@freebsd.org> <87FFDA99-ADDC-4F56-A3E8-56CCAA544542@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Nov 2014 14:21:15 -0500 (EST) Cc: Konstantin Belousov , Andriy Gapon , Jung-uk Kim , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:21:17 -0000 On Tuesday, November 18, 2014 08:43:09 PM Warner Losh wrote: > On Nov 18, 2014, at 3:21 PM, 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 dur= ing > > suspend as well and the thread issue is a prerequisite for that.=20= > > However, reusing "stop at boundary" may not be quite correct becaus= e you > > probably don't want to block suspend because you have an NFS reques= t 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 re= sume > > completes. >=20 > I=E2=80=99m almost certain you don=E2=80=99t want to =E2=80=9Cunmount= =E2=80=9D the filesystems. This would > invalidate all open file handles and would be mondo-bado, and would o= nly > succeed if you forced this issue due to all the open references. Perh= aps > you=E2=80=99re being imprecise. Yes, there should have been quotes around unmount. I want a=20 VFS_SUSPEND/VFS_RESUME that for local filesystems (e.g. UFS) does the o= n-disk=20 equivalent of unmount. (Flush dirty buffers and mark filesystem as cle= an.) =20 You really want this for S4 and even for S3 so you don't have to fsck i= f=20 resume fails. BTW, I think for network or userland filesystems you jus= t punt=20 on this (i.e. VFS_SUSPEND is a no-op or best-effort at most) --=20 John Baldwin