Date: Sat, 1 Mar 1997 13:41:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: terry@lambert.org, freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf options Message-ID: <199703012041.NAA05524@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.95.970301125915.15992D-100000@parkplace.cet.co.jp> from "Michael Hancock" at Mar 1, 97 01:11:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's silly to think you can have "too many vnodes"... what resource > > that is usable are you preventing starving by hard limiting them? > > How do you run a program to take advantage of the resource you > > "saved" this way, if the program you want to run won't run because > > you are out of vnodes? ...Silly. > > It's a non-decreasing pool of memory, some might want a limit on it's > growth so that currently running processes and other kernel functions > aren't negatively affected. Well, the fact that it's a non-decreasing pool is one problem. The way to fix that particular problem is to allocate the vnode internal to the in core inode structure containing the dinode, and make a VFS specific VRELEASE(). That kills both problems with one stone. > Having a non-decreasing pool makes it a little less complicated in the fs > code. You only need to worry about the validity of the contents of a vp > and not the validity of the vp itself. You shouldn't have to worry about it anyway -- vnode references should be counting references. The magic on that is to get rid of the seperate vnode pool (as above), kill off vclean() (as I constantly yell 8-)), and to treat existance in the cache as if it were a reference as well. > The code is complicated as it is, have you looked at the lite2 stuff? I have. It has problems in that it is call-through instead of veto based. People don't seem to understand why I try to make the disctinction; I asked David "how does it make it harder?" when he claimed veto would make writing FS layers harder (I was claiming easier). David didn't ever really answer the question. One *real* problem is that any call-through is going to increase the amount of state held, and is going to increase the number of exposed kernel interfaces called by a VFS layer. Makes things real complicated right off the bat. Bletch. > Whew, I feel like we need something like SUN's lint_lock aka. warlock. > > NOTE(LOCK_RELEASED_AS_A_SIDE_EFFECT); > > The boundaries between a consistent state and an inconsistent state are > pretty tough to follow. This is why I also constantly argue for single-entry/single-exit: the better to track resource holders. Locking, in the traditional sense, isn't terribly necessary. All you *really* have to worry about is context reentrancy tracking... meaning a lot less things need locking. The Sun Solaris SMP conversion for FS reeentrany is wrong (IMHO); a better example is the Unisys SVR4.0.2 ES/MP conversion for their 6000/50, which they developed in parallel with the USL SVR4/2 SMP stuff. In any case, even if it isn't lint code, there should be comments on lock state in and out for any state transitions, anyway, just to let the code be maintainable at all. A lot of NFS problems have arisin lately from not looking at "the big picture" -- instead there are hacks upon hacks to make errors go away, with no real plan. The code is (obviously) falling apart as a result. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703012041.NAA05524>