From owner-freebsd-stable Mon Apr 2 16:50:25 2001 Delivered-To: freebsd-stable@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 6E94637B718 for ; Mon, 2 Apr 2001 16:50:21 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: by arg1.demon.co.uk (Postfix, from userid 300) id 84F599B14; Tue, 3 Apr 2001 00:50:19 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by arg1.demon.co.uk (Postfix) with ESMTP id 7D21B5D12; Tue, 3 Apr 2001 00:50:19 +0100 (BST) Date: Tue, 3 Apr 2001 00:50:19 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Greg Lehey Cc: freebsd-stable@freebsd.org Subject: Re: 4.3-RC processes stuck sleeping on "inode" (?vinum) problem update In-Reply-To: <20010402182909.A75576@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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