Messages in this thread | | | Date | Sat, 12 Jul 2003 18:44:28 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [patch] SCHED_SOFTRR linux scheduler policy ... |
| |
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/
| |