Re: 2.5.74-mm1

Daniel Phillips
2003-07-07T17:40:20Z

On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Jamie Lokier wrote:
> > Davide Libenzi wrote:
> > > The scheduler has to work w/out external input, period.
> >
> > Can you justify this?
> >
> > It strikes me that a music player's thread which requests a special
> > music-playing scheduling hint is not unreasonable, if that actually
> > works and scheduler heuristics do not.
>
> Jamie, looking at those reports it seems it is not only a sound players
> problem.

You still seem to be having trouble with the idea that the sound servicing
thread is a realtime process, and thus fundamentally different from other
kinds of processes. Could you please explain why you disagree with this?

> The *application* has to hint the scheduler, not the user.

Partly true, in that users should be able to supply the hint in some way, they
desire. However in this case - Zinf - the point is moot, because Zinf is
trying hard to give the hint, but it fails because of above-mentioned
braindamage.

> If reports about UI interactivity are true, this means that there's
> something wrong in the current scheduler though. Besides the player issue.

The current scheduler, complete with Con's tweaks, is working very well for me
in combination with "nice -something". The remaining issue there is pure
policy. In that regard, I'm trying to find the most appropriate way of
fixing up user space so that Zinf's SetPriority actually achieves its
intended effect. Running all logins at some setable non-negative default
priority is the best idea I've seen so far in that regard, and soon my system
will be doing just that. I'll let you know if anything explodes ;-)

If there's a remaining fundamental flaw in the kernel scheduler, it would be
the lower-priority process starvation question, which holds the promise of
plenty of future lkml navel gaz^W^Wdiscussion indeed.

Regards,

Daniel