Date: Tue, 3 Apr 2001 00:50:19 +0100 (BST) From: Andrew Gordon <arg@arg1.demon.co.uk> To: Greg Lehey <grog@lemis.com> Cc: freebsd-stable@freebsd.org Subject: Re: 4.3-RC processes stuck sleeping on "inode" (?vinum) problem update Message-ID: <Pine.BSF.4.21.0104030015090.12196-100000@server.arg.sj.co.uk> In-Reply-To: <20010402182909.A75576@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Apr 2001, Greg Lehey wrote: > plex->lockwaits++; /* waited one more time */ > - tsleep(lock, PRIBIO, "vrlock", 0); > - lock = plex->lock; /* start again */ > + tsleep(lock, PRIBIO, "vrlock", hz); > + lock = &plex->lock [-1]; /* start again */ > foundlocks = 0; > pos = NULL; OK, this seems to work - it's now been up 12 hours. Observing that it had failed during the daily level-1 dumps on each previous occasion when I had been running 4.3-RC, I ran a level 0 dump to /dev/null by way of a stress test. This ran to completion (taking 5hrs12min); while running, I noticed that there was nearly always one (sometimes two) of the dump processes sleeping on "vrlock". I haven't watched it this closely before to know if this is normal, or indicates that the new hz-duration sleep is kicking in frequently. Unfortunately, I don't have an accurate benchmark to tell if performance is affected; a normal level 0 dump (across the network to another machine) takes about 7 hours, but that's limited by the performance of the gzip process running at the other end - so 5 hours for dumping to /dev/null is on the slow side but plausible. Tonight's level 1 dump took 20 minutes compared to yesterday's 10 minutes, despite producing only half the amount of (compressed) output, but that may be a fluke. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104030015090.12196-100000>