From owner-freebsd-hackers Mon Jul 3 13: 0:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 5694237BEFC for ; Mon, 3 Jul 2000 13:00:18 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA08461; Mon, 3 Jul 2000 21:59:37 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bill Fumerola Cc: Bosko Milekic , freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf re-write(s), v 0.1 In-reply-to: Your message of "Mon, 03 Jul 2000 15:40:40 EDT." <20000703154040.V18942@jade.chc-chimes.com> Date: Mon, 03 Jul 2000 21:59:37 +0200 Message-ID: <8459.962654377@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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