Date: Wed, 08 Nov 2000 02:12:34 +0100 From: Andre Oppermann <oppermann@telehouse.ch> To: Bill Fumerola <billf@chimesnet.com> Cc: Paul Saab <paul@mu.org>, Poul-Henning Kamp <phk@freebsd.org>, arch@freebsd.org Subject: Re: Green/Yellow/Red state for the VM system. Message-ID: <3A08A882.AA428418@telehouse.ch> References: <28041.973635706@critter> <3A088D1B.96157C0D@telehouse.ch> <20001107153343.A24788@elvis.mu.org> <3A0892BB.4F399708@telehouse.ch> <20001107184940.X37870@jade.chc-chimes.com> <3A0896EC.A2CA3106@telehouse.ch> <20001107192754.Y37870@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fumerola wrote: > > On Wed, Nov 08, 2000 at 12:57:32AM +0100, Andre Oppermann wrote: > > > If you had read my previous email further, instead of just stopping > > after the first sentence that apparently offended you, you would have > > seen that I come to the same conclusion with the twist that the change > > of behaviour should happen on a per sub-system basis, not on a global > > kernel-KVM basis. > > I think that a subsystem variable could have value, but there are portions > of the kernel that an attack on one subsystem has a large effect on others. Yes, that's why each subsystem should look after it's own business. Let's have an example: There is a DoS attack being launched with thousands of TCP connections to some port. Now let's assume this would use up all available KVM resources. The thousand-and-first TCP connection cannot be handled anymore because there is no free KVM any more. Now the INET Networking subsystem has two options: 1) make some resources available, eg. drop all fin_wait connections, 2) refuse to accept this connection. OK, of course the VM I/O is seeing the same problem, no more memory available. So it has to look also after it's own business and clean up, flush caches etc. So you are absolutely right in saying that an attack or heavy usage on one subsystem has an effect on others. But I say in this case don't tell the VM to make memory free for the INET subsystem. Because if you do that you get a situation where one subsystem can monopolize the available system resources more or less which makes an possible DoS attach or just an heavy usage case much more effective; the whole system breaks down, even the not directly related parts of it. We don't allow this in userland, why should we do in the kernel? The right solution is to promote the information of shortage back to the originator but not let one part of the system take it all. In a subsystem local solution the resource distribution would look like this (in the KVM): Normal operation; INET 20%, VMIO 20%, 60% free Some app processing logs; INET 20%, VMIO 40%, 40% free TCP attack begins; INET 60%, VMIO 40%, 0% free Now each subsystem has it got it's max as available right now and have to live with it. easy. INET has chew on the TCP connections but the application processing logs is still alive and proceeding. OK, the VMIO will not get any more memory and has to complete the outstanding I/O before doing new but it's not dead in the water. Lets have a look what would happen if set now the proposed global emergency flag in the VM: Global emergency flag; INET 90%, VMIO 10%, 0% free Ugh, the application doing log processing comes to a grinding halt and the INET sucks every available byte in to handle the attack. I would say that's a really sucessful attack! The idea of subsystem local shortage handling is to maintain state. You can keep what you have but you don't get any more if we are in a shortage case. Of course the systems performace will be degraded but it will not drop down on the floor. Important is to make the subsystems dead-lock free if they can't get any more memory and teach them how to free stuff for themselfes, not the others, to continue operation. -- Andre 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?3A08A882.AA428418>