Date: Sat, 13 May 2000 04:40:06 -0700 (PDT) From: Tim Vanderhoek <vanderh@ecf.utoronto.ca> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/10172 Message-ID: <200005131140.EAA43822@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/10172; it has been noted by GNATS. From: Tim Vanderhoek <vanderh@ecf.utoronto.ca> To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/10172 Date: Sat, 13 May 2000 07:32:40 -0400 [verbatim from -arch list] ----- Forwarded message from Poul-Henning Kamp <phk@critter.freebsd.dk> ----- To: arch@freebsd.org Subject: Re: vfs.cache.maxaliases Date: Tue, 09 May 2000 14:48:59 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> In message <Pine.BSF.4.21.0005092228470.7696-100000@besplex.bde.org>, Bruce Eva ns writes: >Did the user kmem exhaustion service in the name cache doesn't seem to be >fixed in RELENG_4 or -current. Only RELENG_3 has vfs.cache.maxaliases. Right, it isn't, it's not fixed in RELENG_3 either but a big ugly roadblock has been put down for it. We currently have a variant of the problem affecting some machines: Imagine a 4GB RAM machine caching a lot of one-page vnodes -> we run out of KVM for the vnodes. I think the right solution consists of two things: 1. A global kernel flag which tells us how we are doing KVM wise: enum {KVM_OK, KVM_LOW, LVM_VERYLOW, KVM_EMPTY} kvm_state; This variable will be maintained by the VM system, and other subsystems can use it to determine their behaviour. 2. An emergency call back list for when we are desparately low on KVM. For the namecache the right behaviour would then be: When adding a new entry: kvm_state == KVM_OK business as ususal kvm_state == KVM_LOW free at least two entries and at least as many bytes as we are going to allocate before adding a new entry. kvm_state == KVM_VERYLOW free at least five entries, do not allocate new entry. kvm_state == KVM_EMPTY free entire cache callback: free entire cache The vnode cache can be made to gracefully react in a similar way. Such a scheme will allow us to gracefully avoid running out of KVM and at least it will survive all DoS attacks on the namecache which I am aware off. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message ----- End forwarded message ----- -- Signature withheld by request of author. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005131140.EAA43822>