Date: 12 Apr 1999 12:59:59 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: Warner Losh <imp@harmony.village.org> Cc: current@freebsd.org Subject: Re: DoS from local users (fwd) Message-ID: <86k8vignvk.fsf@not.demophon.com> In-Reply-To: Warner Losh's message of "12 Apr 1999 02:39:50 %2B0300" References: <199904102057.PAA27724@home.dragondata.com> <199904112100.PAA05104@harmony.village.org.newsgate.clinet.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@harmony.village.org> writes: > In message <199904102057.PAA27724@home.dragondata.com> Kevin Day writes: > : 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. > > I've seen some experimental patches in the past that try to do just > this. However, there are some problems. What if uid 1002's process > does a sleep. Should the 40 processes that 1001 just get 50% of the > cpu? Or should there be other limits. It turns into an interesting > research problem in a hurry. That's a simple matter of implementation decisions. Naturally there's hardly ever a good reason to keep a processor idle, so the limits should only apply when the processor would not otherwise be idle. How this affects the amount of runtime the processes get later depends on how you compute percentages. An example approach is what the class scheduling feature in Digital UNIX does. I'll describe it from what I remember from playing with it a couple of years ago, so all of this is only true IIRC. It has some fixed scheduling period, for which it allocates cycles for that period to scheduling classes (threads, users, groups, whatever) based on the percentage limits. The only addition to the scheduler is having threads consume these cycles from the scheduling classes. When those cycles have been used up, threads in that class are not allowed to run. If an eligible processor would otherwise be idle, they may be allowed to run despite this (the behavior is configurable in some scope, I can't remember whether it was global or per class). The class scheduler in Digital UNIX is, in many respects, a kludge, and I'm not recommending that FreeBSD implement a similar mechanism. But it is semantically "sane", and unlikely to cause additional problems when configured with reasonable parameters. 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?86k8vignvk.fsf>