From owner-freebsd-bugs@FreeBSD.ORG Fri Oct 12 15:00:10 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4F1E16A417 for ; Fri, 12 Oct 2007 15:00:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 903F113C455 for ; Fri, 12 Oct 2007 15:00:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9CF0AGu009848 for ; Fri, 12 Oct 2007 15:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9CF0AvT009847; Fri, 12 Oct 2007 15:00:10 GMT (envelope-from gnats) Date: Fri, 12 Oct 2007 15:00:10 GMT Message-Id: <200710121500.l9CF0AvT009847@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: dfilter@FreeBSD.org (dfilter service) Cc: Subject: Re: bin/111101: commit references a PR X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2007 15:00:10 -0000 The following reply was made to PR bin/111101; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/111101: commit references a PR Date: Fri, 12 Oct 2007 14:57:04 +0000 (UTC) csjp 2007-10-12 14:56:52 UTC FreeBSD src repository Modified files: usr.bin/lockf lockf.1 lockf.c Log: Revision 1.12 of lockf.c fixed a "thundering herd" scenario when the lock experienced contention a number of processes would race to acquire lock when it was released. This problem resulted in a lot of CPU load as well as locks being picked up out of order. Unfortunately, a regression snuck in which allowed multiple threads to pickup the same lock when -k was not used. This could occur when multiple processes open a file descriptor to inode X (one process will be blocked) and the file is unlinked on unlock (thereby removing the directory entry allow another process to create a new directory entry for the same file name and lock it). This changes restores the old algorithm of: wait for the lock, then acquire lock when we want to unlink the file on exit (specifically when -k is not used) and keeps the new algorithm for when -k is used, which yields fairness and improved performance. Also, update the man page to inform users that if lockf(1) is being used to facilitate concurrency between a number of processes, it is recommended that -k be used to reduce CPU load and yeld fairness with regard to lock ordering. Collaborated with: jdp PR: bin/114341 PR: bin/116543 PR: bin/111101 MFC after: 1 week Revision Changes Path 1.19 +13 -1 src/usr.bin/lockf/lockf.1 1.17 +59 -10 src/usr.bin/lockf/lockf.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"