From owner-freebsd-arch@FreeBSD.ORG Wed Nov 19 10:16:10 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 9ADBEBBC; Wed, 19 Nov 2014 10:16:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08613E89; Wed, 19 Nov 2014 10:16:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAJAG5wJ003706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2014 12:16:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAJAG5wJ003706 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAJAG5fE003705; Wed, 19 Nov 2014 12:16:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Nov 2014 12:16:05 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: suspending threads before devices Message-ID: <20141119101605.GB17068@kib.kiev.ua> References: <201203202037.q2KKbNfK037014@svn.freebsd.org> <54676BA6.7000202@FreeBSD.org> <20141115180014.GK17068@kib.kiev.ua> <201411181721.56505.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411181721.56505.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Jung-uk Kim , Andriy Gapon , "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 10:16:10 -0000 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.