Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 11 Aug 2003 21:46:00 +0200 | From | Mike Galbraith <> | Subject | Re: [PATCH]O14int [SCHED_SOFTRR please] |
| |
At 08:19 PM 8/11/2003 +0200, Roger Larsson wrote: >On Sunday 10 August 2003 13.17, Mike Galbraith wrote: > > At 01:48 AM 8/10/2003 -0700, Simon Kirby wrote: > > >I am seeing similar starvation problems that others are seeing in these > > >threads. At first it was whenever I clicked a link in Mozilla -- xmms > > >would stop, sometimes for a second or so, on a Celeron 466 MHz machine. > > > > Do you see this with test-X and Ingo's latest changes too? I can only > > imagine one scenario off the top of my head where this could happen; if > > xmms exhausted a slice while STARVATION_LIMIT is exceeded, it could land in > > the expired array and remain unserviced for the period of time it takes for > > all tasks remaining in the active array to exhaust their slices. Seems > > like that should be pretty rare though. > > > >xmms is a RT process - it does not really have interactivity problems... >It will be extremely hard to fix this in a generic scheduler, instead >let xmms be the RT process it is with SCHED_SOFTRR (or whatever >it will be named). >Do this for arts, and other audio/video path applications.
(For the scenario described, it doesn't matter what scheduler policy is used)
>Then start the race for interactivity tuning > (X, X applications, console, login, etc) > >interactivity = two-way > http://www.m-w.com/cgi-bin/dictionary?va=interactive > >Listening to music is not interactive.
?!? <tilt> What makes you say that? What in the world am I doing when I fire up xmms? (can't be the two way thing... that's happening until I stop listening)
-Mike
-Mike
- 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/
| ![\](/images/icornerr.gif) |