Re: [patch] SCHED_SOFTRR linux scheduler policy ...

Davide Libenzi (davidel@xmailserver.org)
Sat, 12 Jul 2003 18:44:28 -0700 (PDT)


On Sat, 12 Jul 2003, Jamie Lokier wrote:

> Miguel Freitas wrote:
> > > I'm wondering what happens if the tasks are both good, early to bed
> > > without a fuss. Neither runs their entire timeslice.
> > >
> > > Or to illustrate: say xine uses 10% of my CPU. What happens when I
> > > open 11 xine windows?
> >
> > well of course 110% is more than what you have of resources and xine
> > would have to drop frames to keep it up... :)
>
> That's fine. The problem is, does this completely starve the other
> tasks such as kswapd, ksoftirqd, bash etc.?
>
> The real problem is can a user accidentally or malicious lock up a box
> using SCHED_SOFTRR (when xmms, xine, GNU software radio and modem are
> all using it :), and also what about multi-user boxes, can two users
> accidentally break it.
>
> Perhaps there should be a _global_ maximum amount of CPU used in
> SCHED_SOFTRR beyond which SCHED_SOFTRR tasks get downgraded.

You need per-user policies to achieve fairness, the global allocation
won't work. You need global fairness towards tasks != SOFTRR *and* local
fairness towards tasks == SOFTRR. If you limit globally the maximum time
that SOFTRR tasks can suck, you'll achieve global fairness. But you do not
prevent a single user to suck most of this slice by creating many SOFTRR
tasks (or exploits). I can easily fix this if someone will show real
interest in the thing. Since it has been a while that I was not
looking at the scheduler, yesterday I googled a little bit and I saw
that there are a few issues where you do not need SOFTRR to completely
starve other tasks though (the irman thingy for example). IMHO these
should be discussed before going in 2.6, to either fix them or publicly
recognize them as "Not A Bug".

- Davide

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/