In message <[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
