Task switch overhead is accounted for by goodness(), no? If not, then
it should be.
> o RT tasks have static priorities, and would also be affected
If by RT tasks you mean SCHED_RR then we do exactly the right thing
for them. For SCHED_FIFO see below.
> now, what happens if there is a SCHED_FIFO thread w/ priority=50 running
> and another one becomes runnable?...
Oops. I assumed the new one is added at the end of the runqueue (as
the man page says). In reality it's added at the beginning, see
wake_up_process() and setscheduler(). This (the current behaviour) is
wrong, according to "man sched_setscheduler". I don't have a copy of
the relevant POSIX standard so I can't check there. That's easily
fixable, I'll post an updated patch.
> > Sure. That's why I'm aiming for a minimal patch. I'd be happy with
> > yours too, though, minus the special case for prev.
>
> what "special case for prev"? ;) You just traded one check for
> another...
True. I can argue that my special case triggers less often that the
old special case but I won't. I guess I can also bundle my new check
with the move_rr_last like you do in your patch.
What I meant by "special case for prev" is this logic: "If the
previous process is still runnable then make it the default, only then
start going through the runqueue." I don't like that for two reasons:
1. I think it's unnecessary policy - prev is still in the runqueue and
goodness() should be the only criterion for selection. 2. It gets in
my way.
<ASIDE>
Here is what I want to do: I'm writing a "fair" scheduler (see
http://www.cs.umass.edu/~lass/software/qlinux/). I will have several
separate runqueues. In schedule() I first select a runqueue and then
choose a process from that runqueue. In this scheme it makes no sense
to make prev the default process to run, since it might belong to the
wrong runqueue. If the standard scheduler didn't do that, then the
modifications I need to in schedule() are a lot nicer and localized.
</ASIDE>
> There is code like this (example from __get_free_pages()):
> > /*
> > * If we can schedule, do so, and make sure to yield.
> > * We may be a real-time process, and if kswapd is
> > * waiting for us we need to allow it to run a bit.
> > */
> > if (gfp_mask & __GFP_WAIT) {
> > current->policy |= SCHED_YIELD;
> > schedule();
> > }
>
> this assumes the SCHED_YIELD flag will prevent the current task from
> being selected if there's anything else to run. Other than being
> "wrong" from a modular pov, it's also wrong because that's not what
> SCHED_YIELD actually does. Not even in the stock scheduler...
I see.
> If anybody can see any problems left with the scheduler i'd certainly
> like to know...
See above about SCHED_FIFO/SCHED_RR processes going to the beginning
of the runqueue rather than the end when woken up.
Regards,
Borislav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/