From owner-freebsd-current@FreeBSD.ORG Mon May 27 06:07:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD16D554; Mon, 27 May 2013 06:07:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31BEA34E; Mon, 27 May 2013 06:07:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4R67RcZ058612; Mon, 27 May 2013 09:07:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4R67RcZ058612 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4R67R4J058611; Mon, 27 May 2013 09:07:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 May 2013 09:07:27 +0300 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: FreeBSD-HEAD gets stuck on vnode operations Message-ID: <20130527060727.GW3047@kib.kiev.ua> References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> <51A275F7.9030401@citrix.com> <20130526222254.GB40375@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JVkQSGY1i+HoDREx" Content-Disposition: inline In-Reply-To: <20130526222254.GB40375@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, "current@freebsd.org" , Roger Pau Monn? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 06:07:44 -0000 --JVkQSGY1i+HoDREx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: > On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: > > On 26/05/13 22:20, Jilles Tjoelker wrote: > > > Instead of a pause() that may be too short or too long, how about > > > waiting for the necessary lock? In other words, replace the kern_yiel= d() > > > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > > > to acquire two locks without imposing an order between them. >=20 > > Since there might be more than one locked vnode, waiting on a specific > > locked vnode seemed rather arbitrary, but I agree that the pause is also > > rather arbitrary. >=20 > > Also, can we be sure that the v_interlock mutex will not be destroyed > > while the syncer process is waiting for it to be unlocked? >=20 > I think this is a major problem. My idea was too easy and will not work. >=20 > That said, the code in mnt_vnode_next_active() appears to implement some > sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms > (default value of hogticks) and then yields. This is far too long for a > mutex lock and if it takes that long it means that either the thread > owning the lock is blocked by us somehow or someone is abusing a mutex > to work like a sleepable lock such as by spinning or DELAY. >=20 > Given that it has been spinning for 200ms, it is not so bad to pause for > one additional microsecond. >=20 > The adaptive spinning was added fairly recently, so apparently it > happens fairly frequently that VI_TRYLOCK fails transiently. > Unfortunately, the real adaptive spinning code cannot be used because it > will spin forever as long as the thread owning v_interlock is running, > including when that is because it is spinning for vnode_free_list_mtx. > Perhaps we can try to VI_TRYLOCK a certain number of times. It is also > possible to check the contested bit of vnode_free_list_mtx > (sys/netgraph/netflow/netflow.c does something similar) and stop > spinning in that case. >=20 > A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority =66rom the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. --JVkQSGY1i+HoDREx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRovgfAAoJEJDCuSvBvK1BmNIP/je3R6P5ySJnhK1RdeHvYCuV GElJUmlP7IC8b+PLK3Hr+FcjWITFPIpGsjDR4znGJ1tgrbBlEA41BbZbZYHMhBG2 2VrK4yJmFZVSV2SAMjaFEORqz8vbI9fJrt7SUSbYFUtPudM3Iyt6KtBjuEfR5oWA t2NYpN8T5Kxp027kKr5Yy335bDhLYSOSQ0OoFdJjcCle4ZHjSfKzPYNW/NJ6QVVE m4VXvHXSzWznKwl2M9lgvVb6PLFgwkoNEYqNb1qVgtrGSehJAdfBfm/1XoJbnt7F Jm7jOKBNfnttY26DH3gJLFN02dw6G0BLwJ3Krf/a6xmUxtNAWOMxNHd4/u33yqD+ oxM3QQh/Sbb4GwRpRYxsh97qZ7vuGLuhQ5OwneJ1colRobktHkfhvxM12VGRf/iX +s06qmBIeRdpjv78SvCGFdpQGUuaKQH0w3XCnEZ5uA9h5WFCptB888EKGpoPRnCO R8cjgZ3FiJTmEpHRPhWDZdAvxoEiNaRVPJuoPYKR3UnCJ+QJMLkC4xgQflzZAs94 WjwBKc4JVbz4AV4YDjYkkWok5Tz2O9ZKP8vxJv1UAEhqAu+mzLcr3nbdhdOUoIw3 uKh5z6AwpCa+TPju2wm5mZPpjt26jb94sKpL0yGk74xTFZNAzjh6AwUY/rvAxLP4 +wdJmMMp5HXNhOQnaada =B3in -----END PGP SIGNATURE----- --JVkQSGY1i+HoDREx--