Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Sep 1997 14:51:32 -0500
From:      Karl Denninger  <karl@mcs.net>
To:        Nate Williams <nate@mt.sri.com>
Cc:        Karl Denninger <karl@mcs.net>, Poul-Henning Kamp <phk@critter.freebsd.dk>, current@freebsd.org
Subject:   Re: WARNING! Builds from the last few days have BROKEN NFS
Message-ID:  <19970927145131.64000@Mars.Mcs.Net>
In-Reply-To: <199709271942.NAA27353@rocky.mt.sri.com>; from Nate Williams on Sat, Sep 27, 1997 at 01:42:20PM -0600
References:  <19970927124917.57478@Mars.Mcs.Net> <6979.875383880@critter.freebsd.dk> <19970927132318.04053@Mars.Mcs.Net> <199709271942.NAA27353@rocky.mt.sri.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 27, 1997 at 01:42:20PM -0600, Nate Williams wrote:
> Karl wrote:
> >All -current builds from the last few days have BROKEN NFS client code.
> 
> Poul-Henning responded:
> > Please try
> >	sysctl -w debug.wantfreevnodes=0
> 
> > Uh, the problem with that Paul is that a build from the sources as they
>                             ^^^^
> Poul-Henning
> 
> > existed on the 19th does *not* exhibit the problem (which is what I'm
> > running now).  I believe that the critical change actually occurred mid-week
> > this last week when a set of files in the vm subdirectory were
> > modified.
> 
> phk         1997/09/25 09:18:00 PDT
> 
>   Modified files:
>     sys/kern             vfs_subr.c 
>   Log:
>   Reduce the target number of vnodes on the freelist from desiredvnodes
>   (usually a couple of thousand) to 25.  The measured impact on cache-hits
>   doesn't justify spending memory this way:
> 
> That was in the middle of the week, but wasn't in the VM system.
> 
> 'Just do it, and quit 'yer arguing' :) :) :) :)
> 
> Nate
> 
> ps. Things like this are pretty trivial to find if you have the CVS
> tree.  Go look at the $CVSROOT/CVSROOT/commitlog/sys, and search for
> '/1997/09/19', and look at the messages after that point.  Other
> significant kernel changes this week including using the zone allocator
> for M_NAMEI (dyson), timeout changes (gibbs), SMP stuff (various), all
> of which are easily seen in the commitlogs.

I understand how to find the commit logs :-)

I also understand how to roll the change back with the "-D" option.

What I don't understand is why this kind of change would have the effect
that it is having.  That is, why would reducing the target number of vnodes
on the freelist lead to hangs in a disk wait ("D") which are unkillable?

The SMP stuff is not relavent to me right now, because I'm not running an
SMP system anywhere (yet) :-)  

I guess what I'm asking is how do we know that this really caused it?
Is it not possible that the zone allocator changes are also responsible
here?

I'm trying to understand both the reason for the code changes and why they
broke what was, until then, a reasonably stable kernel (there is still some
odd stuff going on in the NFS code, and I'm using V1.41 of nfs_bio.c, as 
its the last one which is stable and doesn't lead to panics in NFS clients.)

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970927145131.64000>