cvs commit: src/sys/kern vfs_subr.c

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Apr 4 13:47:30 PDT 2005


In message <20050404203830.GB60345 at elvis.mu.org>, Alfred Perlstein writes:

>>   Modified files:
>>     sys/kern             vfs_subr.c 
>>   Log:
>>    - Instead of waiting forever to get a vnode in getnewvnode() wait for
>>      one to become available for one second and then return ENFILE.  We
>>      can run out of vnodes, and there must be a hard limit because without
>>      one we can quickly run out of KVA on x86.  Presently the system can
>>      deadlock if there are maxvnodes directories in the namecache.  The
>>      original 4.x BSD behavior was to return ENFILE if we reached the max,
>>      but 4.x BSD did not have the vnlru proc so it was less profitable to
>>      wait.
>
>This sounds really bad, can't a callback be made into the
>namecache first to purge unused records before doing this?
>
>Or is there already some sort of facility that already does
>this?

I tried to talk with Jeff about this last week.

Currently we do the backpressure in the pageout daemon and we do it
so to speak, when we fear the damage may already have happened.

I am very unhappy with this approach and would like to see the
pageout daemon (or some other suitable bit of code) make a global
variable available which gives an indication of the overall state
of VM availability so that subsystems like the vfs namecache can
adapt their behaviour already when we see the first signs.

A simple
	enum vmload {
		VM_PLENTY,
		VM_TIGHT,
		VM_OUT,
		VM_PANIC
	}

would do wonders.

In VM_TIGHT the vfs namecache would drop an entry each time it
wanted to create one.  In VM_OUT it would drop two entries every
time it creates one, in VM_PANIC it would ditch the entire cache.

The advantage to having a variable is that it is a very cheap
test with no locking hangups in the relevant codes own context,
it is not a callback or eventhandler which comes in and needs
to get all the locking in order etc.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the cvs-all mailing list