Date: Tue, 07 Nov 2000 21:17:45 -0500 (EST) From: Bosko Milekic <bmilekic@dsuper.net> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. Message-ID: <Pine.BSF.4.21.0011072105520.79678-100000@jehovah.technokratis.com> In-Reply-To: <28041.973635706@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011072105520.79678-100000>