Re: [SHED] Questions.

[Ian Kumlien <pomac@vapor.com>]

[-- Attachment #1: Type: text/plain, Size: 4699 bytes --]

On Mon, 2003-09-01 at 04:50, Con Kolivas wrote:
> On Mon, 1 Sep 2003 10:00, Ian Kumlien wrote:
> > On Mon, 2003-09-01 at 01:41, Robert Love wrote:
> > > This implies that a high priority, which has exhausted its timeslice,
> > > will not be allowed to run again until _all_ other runnable tasks
> > > exhaust their timeslice (this ignores the reinsertion into the active
> > > array of interactive tasks, but that is an optimization that just
> > > complicates this discussion).
> >
> > So it's penalised by being in the corner for one go? or just pri
> > penalised (sounds like it could get a corner from what you wrote... Or
> > is it time for bed).
> 
> Please read my RFC 
> (http://marc.theaimsgroup.com/?l=linux-kernel&m=106178160825835&w=2) which 
> has this extensively explained. If this were the case after one timeslice, 
> then dragging a window in X at load of say 32 would be impossible; the window 
> would move for 0.1 second, stand still for 3.2 seconds then move for another 
> 0.1 second.

Thats nicely written, but it feels very complex...
The more i read it the more i like the "currency" implementation in
Executive (since i never understood how feedback worked exactly, it was
a while ago since i read it).

Just give all processes money to spend on cpu time... Set a high limit
and let em spend =)

> > > > Damn thats a tough cookie, i still think that the priority inversion is
> > > > bad. Don't know enough about this to actually provide a solution...
> > > > Any one else that has a view point?
> > >
> > > Priority inversion is bad, but the priority inversion in this case is
> > > intended.  Higher priority tasks cannot starve lower ones.  It is a
> > > classic Unix philosophy that 'all tasks make some forward progress'
> >
> > Yes, like the feedback scheduler...
> 
> Priority inversion to some extent will exist in any scheduler design that has 
> priorities. There are solutions available but they incur a performance 
> penalty elsewhere (some people are currently experimenting). The inversion 
> problems inherent in my earlier patches are largely gone with the duration 
> and severity of inversion being either equal to or smaller than the instances 
> that occur in the vanilla scheduler. Nick's approach may work around it 
> differently but documentation is hard to find (hint Nick*).

What i meant with priority inversion is that highpri should have small
timeslices and low pri should have large... Sorry if i was unclear.
(maybe the same size timeslice but separated in to timeunits)

> > > > Hummm, the skips in xmms tells me that something is bad..
> > > > (esp since it works perfectly on the previus scheduler)
> > >
> > > A lot of this is just the interactivity estimator making the wrong
> > > estimate.
> >
> > Yes, But... When you come from AmigaOS, and have used Executive...
> > things like this is dis concerning. Executive is a scheduler addition
> > for amigaos that has many schedulers to choose from. One of which is the
> > original feedback scheduler. While a feedback scheduler consumes some
> > cpu it still allows you to play mp3's while surfing the net on a 50 mhz
> > 68060. Hearing about 500mhz machines that skip is somewhat.. odd.
> 
> That's in an attempt to make them as high throughput machines as possible. 
> Xmms skipping is basically killed off as a problem in both Nick's and my 
> patches. If it still remains it is almost certainly a disk i/o problem (no 
> dma) or hitting swap memory.

Humm, ok... The only desktop i have where i have switched between O(1)
and common is my laptop... which sadly didn't run either nick or your
work... So i have no comparison with your or nicks work.

> > Well, there is latency and there is latency. To take the AmigaOS
> > example. Voyager, a webbrowser for AmigaOS uses MUI (a fully dynamic gui
> > with weighted(prioritized) sections) and renders images. It's responsive
> > even on a 40mhz 68040 using Executive with the feedback scheduler.
> 
> Multiple processors to do different tasks on amigas kinda helped there...

Well, yes, but... Not when it comes to scheduling.

> > 500 mhz is a lot of horsepower when it comes to playing mp3's and
> > scheduling.. It feels like something is wrong when i see all these
> > discussions but i most certainly don't know enough to even begin to
> > understand it. I only tried to show the thing i thought was really wrong
> > but you do have a point with the runqueues and timeslices =P
> 
> Things are _never ever ever ever_ as simple as they appear on the surface.

If they were... Life would be boring =P

-- 
Ian Kumlien <pomac@vapor.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]