Date: Fri, 30 Sep 2005 03:27:11 +0000 From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_bio.c vfs_subr.c src/sys/sys buf.h proc.h src/sys/ufs/ffs ffs_snapshot.c Message-ID: <20050930032711.GA24607@freefall.freebsd.org> In-Reply-To: <200509300130.j8U1U2nb098515@repoman.freebsd.org> References: <200509300130.j8U1U2nb098515@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hooooorraay! On Fri, Sep 30, 2005 at 01:30:02AM +0000, Don Lewis wrote: > truckman 2005-09-30 01:30:01 UTC > > FreeBSD src repository > > Modified files: > sys/kern vfs_bio.c vfs_subr.c > sys/sys buf.h proc.h > sys/ufs/ffs ffs_snapshot.c > Log: > Un-staticize runningbufwakeup() and staticize updateproc. > > Add a new private thread flag to indicate that the thread should > not sleep if runningbufspace is too large. > > Set this flag on the bufdaemon and syncer threads so that they skip > the waitrunningbufspace() call in bufwrite() rather than than > checking the proc pointer vs. the known proc pointers for these two > threads. A way of preventing these threads from being starved for > I/O but still placing limits on their outstanding I/O would be > desirable. > > Set this flag in ffs_copyonwrite() to prevent bufwrite() calls from > blocking on the runningbufspace check while holding snaplk. This > prevents snaplk from being held for an arbitrarily long period of > time if runningbufspace is high and greatly reduces the contention > for snaplk. The disadvantage is that ffs_copyonwrite() can start > a large amount of I/O if there are a large number of snapshots, > which could cause a deadlock in other parts of the code. > > Call runningbufwakeup() in ffs_copyonwrite() to decrement runningbufspace > before attempting to grab snaplk so that I/O requests waiting on > snaplk are not counted in runningbufspace as being in-progress. > Increment runningbufspace again before actually launching the > original I/O request. > > Prior to the above two changes, the system could deadlock if enough > I/O requests were blocked by snaplk to prevent runningbufspace from > falling below lorunningspace and one of the bawrite() calls in > ffs_copyonwrite() blocked in waitrunningbufspace() while holding > snaplk. > > See <http://www.holm.cc/stress/log/cons143.html>; > > Revision Changes Path > 1.495 +3 -3 src/sys/kern/vfs_bio.c > 1.648 +2 -1 src/sys/kern/vfs_subr.c > 1.190 +1 -0 src/sys/sys/buf.h > 1.436 +1 -1 src/sys/sys/proc.h > 1.104 +16 -4 src/sys/ufs/ffs/ffs_snapshot.c -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050930032711.GA24607>