From owner-svn-src-head@freebsd.org Wed Aug 31 16:39:50 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00C39BCAC61; Wed, 31 Aug 2016 16:39:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 9F22EFE7; Wed, 31 Aug 2016 16:39:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7VGdhj7096286 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 31 Aug 2016 19:39:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7VGdhj7096286 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7VGdhav096285; Wed, 31 Aug 2016 19:39:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 31 Aug 2016 19:39:43 +0300 From: Konstantin Belousov To: Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r305129 - head/sys/vm Message-ID: <20160831163943.GE83214@kib.kiev.ua> References: <201608311449.u7VEnwlq064219@repo.freebsd.org> <20160901011048.T45881@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160901011048.T45881@besplex.bde.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 16:39:50 -0000 On Thu, Sep 01, 2016 at 01:38:31AM +1000, Bruce Evans wrote: > On Wed, 31 Aug 2016, Konstantin Belousov wrote: > > > Log: > > Make swapoff reliable. > > > > The swap_pager_swapoff() function uses trylock for the object lock > > before pagein, which means that either i/o to md(4) over swap, or > > intensive page faults over swap pager objects might prevent swapoff() > > from making any progress. Then the retry < 100 check fails and machine > > panics. > > > > If trylock fails, acquire the object lock in the blockable way and > > restart the hash bucket walk. Keep retries logic for now. > > Trylock is difficult to use. When it fails, there is no way for the > caller to tell how long it should wait before retrying (much like EAGAIN > errors for userland). Sometimes there is deadlock so retrying is worse > than useless. Sometimes trylock can detect deadlock, but callers never > can (otherwise they wouldn't try). It is actually a way for the caller to tell how long to wait. The lock should be taken in blockable or sleepable way. Issue is that we have to drop other locks, to avoid LOR, and restart the algorithm. This approach, i.e. try fast to get lock with trylock, and do the slow reset on failure with the required lock already held or not, is very common pattern. E.g. it is used in vm_fault() to handle LOR between vnode lock and vm map lock, it is used in ufs_rename() to avoid LORs between all vnode locks participating in rename, and in many other places. > > My version of mtx_trylock_spin_flags() has a timeout in usec. It returns > immediately if deadlock is detected. The timeout is just for convenience > in simple cases where the caller want to aquire the lock normally but > doesn't want the unbounded timeout or panic given by > mtx_trylock_spin(). The important thing is to return error codes like: > - EDEADLK for deadlock detected (e.g., when the CPU running the thread > holding the lock is stopped) > - EMAYBEDEADLK when deadlock is almost detected (e.g., when CPUs are being > stopped) > - EAGAIN when no problem is detected but the lock is held > - ERECURSE when the lock is held but acquiring it recursively would work > if the caller asked for that > - ELOR if acquiring the lock would work but give a LOR, and the caller didn't > ask for LORs. > > The current return value is positive logic for success and doesn't allow > returning error codes. Your use of trylock for console locks is very specific. It is implied by the intent of console output working in any context, which is not needed for typical trylock usage. > > In my applications in console drivers, the caller doesn't want the lock if > it would give a LOR. Without WITNESS, it is too hard to tell if the lock > would give a LOR, but some errors are easy to detect. E.g., acquiring > sleep lock in a critical section. Indeed.