Re: [PATCH] Faster scheduler and separate RT run queue

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 30 Sep 1998 15:32:45 +1000

Linus Torvalds writes:
>
> On Wed, 30 Sep 1998, Richard Gooch wrote:
> >
> > Linus: I'd like to get your opinion of this patch.
>
> I certainly like the implementation. It's of the "this is how I
> would have wanted it done" category, and essentially looks like
> something I could be very comfortable with.

Thanks. I spent a couple of hours thinking hard about how to make it
both elegant and efficient.

> If it wasn't for me not wanting to do this before the code-freeze,
> it would already be in my kernel. As it is, I'll look at the patch a
> bit more.

Understood. I'm far more interested in getting devfs included prior to
2.2. The last you said anything about this was that it would "probably
go in". Is this still your feeling? Any comments about the timescale?

If you decide you don't want this change for 2.1, can you at least
please include the bugfix for RT processes yielding to lower priority
processes? What we have now is contrary to POSIX.4.

The hunk in question is:

@@ -1488,7 +1512,8 @@
{
spin_lock(&scheduler_lock);
spin_lock_irq(&runqueue_lock);
- current->policy |= SCHED_YIELD;
+ if (current->policy == SCHED_OTHER)
+ current->policy |= SCHED_YIELD;
current->need_resched = 1;
move_last_runqueue(current);
spin_unlock_irq(&runqueue_lock);

although looking again I'd rather have:

@@ -1488,7 +1512,8 @@
{
spin_lock(&scheduler_lock);
spin_lock_irq(&runqueue_lock);
- current->policy |= SCHED_YIELD;
+ if (current->policy == SCHED_OTHER)
+ current->policy = SCHED_OTHER | SCHED_YIELD;
current->need_resched = 1;
move_last_runqueue(current);
spin_unlock_irq(&runqueue_lock);

Regards,

Richard....

-
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/