Date: Tue, 13 Apr 1999 09:05:10 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Kevin Day <toasty@home.dragondata.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, hasty@rah.star-gate.com, dv@dv.ru, green@unixhelp.org, freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) Message-ID: <Pine.BSF.3.96.990413090056.25289A-100000@fledge.watson.org> In-Reply-To: <199904102057.PAA27724@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Apr 1999, Kevin Day wrote: > On the shell servers I run, we've got 200-300 users running tasks. > Occasionally, through intent or misconfiguration, a user either forkbombs, > or gets a large number of processes running sucking lots of cpu. > > I'd like to see an option that makes all the processes run by one uid have > the same weight as one process another uid is running. > > i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid > 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's > 40 processes get 50% cpu shared between them. > > This way, one errant user can't have as significant of an impact. > > Is this plausable? A while ago on -current, I posted a reference to a paper on lottery scheduling in FreeBSD. It allows you to provide scheduling weightings that (on average) share the CPU as described. Do a search of the -current or -hackers archive and it should show up. If not, let me know and I can dig up the reference. I believe it was a section of a CMU Tech Report. I don't know what the source code availability of that is, but it presumably was a month-long project for two grad students or something, so should be quite feasible. However, because processes in kernel mode are non-preemptible, it is impossible to deal with some of the connotations of a hog process. But because these processes are billed for some of the resources they consume in kernel mode (i.e., the CPU spent by their kernel thread), at least that can be taken into account. Matt makes the excellent point in another email that once you have this facility, you need to make sure that your CPU policy actually reflects what you want: do you want some process to displace some other process for "fairness" when fairness impedes throughput in such a way that you might be denying something else service because that something else cannot be represented in the scheduling policy? A combination of priorities and lottery tickets might be the best solution. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.3.96.990413090056.25289A-100000>