[lkml]   [2003]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.022 / U:1.800 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site