Date: Tue, 09 May 2000 14:48:59 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: arch@freebsd.org Subject: Re: vfs.cache.maxaliases Message-ID: <25523.957876539@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 09 May 2000 22:33:28 %2B1000." <Pine.BSF.4.21.0005092228470.7696-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25523.957876539>