From owner-freebsd-arch Tue Nov 7 18:13: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id B0DEF37B479; Tue, 7 Nov 2000 18:12:54 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3O00I66OTGX6@falla.videotron.net>; Tue, 7 Nov 2000 21:12:53 -0500 (EST) Date: Tue, 07 Nov 2000 21:17:45 -0500 (EST) From: Bosko Milekic Subject: Re: Green/Yellow/Red state for the VM system. In-reply-to: <28041.973635706@critter> X-Sender: bmilekic@jehovah.technokratis.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Nov 2000, Poul-Henning Kamp wrote: > The easiest way to deal with overload and DoS attacks is to recognize > them as such, go into defensive mode and weather it. This is a reasonable philosophy. > If we implement a generic facility for this, we will have a lot less > worries about future DoS attacks, because our generic mechanism will > deal with a lot of them on its own. > > The facility I hinted at in an earlier email is this: > > The VM system maintains an enum variables: > > enum {GREEN, YELLOW, RED} kvm_light; > > When kvm_light changes value, a kernel event-handler list is activiated. The problem with this "general" approach is that it would be wrong to apply it on a global scale, in all cases. For instance, subsystems which allocate wired-down pages only to never free them back (but keep them on their cache for performance reasons) can do very little for other subsystems waiting for a page to become available. (I'll bet you're thinking "there goes Bosko with his mbuf cr*p again." :-)) But, really though, having network components start freeing memory, often (but not always) in the form of mbufs or mbuf clusters, isn't going to help out some subsystem X waiting for a page to become available. I propose that the general "flag" system allows the possibility for subsystems to maintain their own private 'flags' to which other subsystems can optionally react to, but not have one single "kvm_state/light" affecting everything, especially when it comes to INET-related things. I'm up for working on this after we're done with more of the SMPng work, as I would not like to damage the general "wave" of things. [...] I suggest that when this does go into full-effect that we look at different "lights" or "states" and partly associate them with uses of certain common functions, such as "malloc()." In other words, malloc() users will have to react differently once they notice a "flag" go up. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. Overall, I like this idea as it has potential to make the system act "smarter" in tight situations, but I would advise everybody to proceed with a more "specifics/finer-grain" approach (as opposed to the _general_ "vm_state" flag approach). Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message