Date: Mon, 03 Jul 2000 21:59:37 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bill Fumerola <billf@chimesnet.com> Cc: Bosko Milekic <bmilekic@dsuper.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 Message-ID: <8459.962654377@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 03 Jul 2000 15:40:40 EDT." <20000703154040.V18942@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000703154040.V18942@jade.chc-chimes.com>, Bill Fumerola writes:
>I'd love to have FreeBSD be able to reclaim memory quicker at the sacrifice
>of a few cpu cycles. Why? Well, the "add more memory" arguement doesn't work
>well when I get DoS attacks that will eat any memory available because they
>can connect quicker then I can reclaim the memory.
I have this dream of a global "VM availability flag":
Imagine if the kernel kept a global variable:
enum {VM_PLENTY, VM_TIGHT, VM_NONE, VM_PANIC} vm_state;
/* VM_PLENTY: No worries */
/* VM_TIGHT: Don't make it any worse if you can avoid it */
/* VM_NONE: Fail if you must, free some if you can */
/* VM_PANIC: "VM, VM, my panic for some VM" */
At least a few pieces of our memory-gobbling code could examine
and adjust their caching behaviour from that. Take the vfs
name-cache as an example:
/* Create a new vfs_name-cache entry */
cache_enter(...)
switch (vm_state) {
case VM_PLENTY:
/* do as today */
break;
case VM_TIGHT:
/* delete at least as many bytes as we add (LRU wise) */
break;
case VM_NONE:
/* delete two entries, don't add the new one */
break;
case VM_PANIC:
/* delete the entire cache */
break;
}
The mbuf allocator can use this to great effect if the various
MGET() calls were labeled according to their importance.
Respecting such a flag in the various kernels provide great resistance
against DoS.
User land processes can benefit from this as well: a sysctl would
allow malloc(3) to investigate this state whenever it had was
dealing with a full page, and if needed it could release all it's
cached pages, possibly even call an optional "GC" callback into
the program to force a realloc(3) sequence in long-running daemons.
(An alternative scenario is to have a SIGVMSTATE defaulting to
ignore which gets sent when the variable changes, but that would
have thundering herd issues if a lot of processes was paged out.)
If only somebody would add that variable, I don't feel like diving
into the VM system right now.
--
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8459.962654377>