From owner-cvs-all@FreeBSD.ORG Mon Apr 4 20:47:30 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 052DE16A4CE; Mon, 4 Apr 2005 20:47:30 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BEB943D54; Mon, 4 Apr 2005 20:47:29 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.1) with ESMTP id j34KlRRW005416; Mon, 4 Apr 2005 22:47:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 04 Apr 2005 13:38:30 PDT." <20050404203830.GB60345@elvis.mu.org> Date: Mon, 04 Apr 2005 22:47:27 +0200 Message-ID: <5415.1112647647@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: cvs-src@FreeBSD.org cc: Jeff Roberson cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2005 20:47:30 -0000 In message <20050404203830.GB60345@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@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.