the attached patch speeds up sched_yield() context switch performance by
about 5%. (This patch depends on the previous bitmap-cleanup patch,
functionality-wise.)
instead of dequeueing/enqueue the task from the same array we can skip a
number of steps even in the generic case. If a yielded task has reached
maximum priority (as they do if they yield a number of times) then we can
skip even more steps - the task only has to be queued to the end of the
runqueue.
Ingo
diff -rNu linux/kernel/sched.c linux/kernel/sched.c
--- linux/kernel/sched.c Mon Jan 28 15:23:50 2002
+++ linux/kernel/sched.c Mon Jan 28 15:24:44 2002
@@ -1084,12 +1112,22 @@
*/
spin_lock_irq(&rq->lock);
array = current->array;
- dequeue_task(current, array);
- if (likely(!rt_task(current)))
- if (current->prio < MAX_PRIO-1)
- current->prio++;
- enqueue_task(current, array);
- spin_unlock_irq(&rq->lock);
+ /*
+ * If the task has reached maximum priority (or is a RT task)
+ * then just requeue the task to the end of the runqueue:
+ */
+ if (likely(current->prio == MAX_PRIO-1 || rt_task(current))) {
+ list_del(¤t->run_list);
+ list_add_tail(¤t->run_list, array->queue + current->prio);
+ } else {
+ list_del(¤t->run_list);
+ if (list_empty(array->queue + current->prio))
+ __clear_bit(current->prio, array->bitmap);
+ current->prio++;
+ list_add_tail(¤t->run_list, array->queue + current->prio);
+ __set_bit(current->prio, array->bitmap);
+ }
+ spin_unlock(&rq->lock);
schedule();
On Mon, 28 Jan 2002, Ingo Molnar wrote:
Hi Ingo,
I'm not an spinlock expert but shouldn't you use spin_unlock_irq() when it
was locked with spin_lock_irq() ?
spin_lock_irq(&rq->lock);
> - spin_unlock_irq(&rq->lock);
> + spin_unlock(&rq->lock);
/Martin
Never argue with an idiot. They drag you down to their level, then beat you with experience.
On Mon, 28 Jan 2002, Martin Josefsson wrote:
> > - spin_unlock_irq(&rq->lock);
> > + spin_unlock(&rq->lock);
> I'm not an spinlock expert but shouldn't you use spin_unlock_irq()
> when it was locked with spin_lock_irq() ?
normally yes, but in this case it's an optimization: schedule() will
disable interrupts within a few cycles, so there is no point in enabling
irqs for a short amount of time.
Ingo
On Mon, 28 Jan 2002, Ingo Molnar wrote:
> > I'm not an spinlock expert but shouldn't you use spin_unlock_irq()
> > when it was locked with spin_lock_irq() ?
>
> normally yes, but in this case it's an optimization: schedule() will
> disable interrupts within a few cycles, so there is no point in enabling
> irqs for a short amount of time.
Thanks for the explanation.
/Martin
Never argue with an idiot. They drag you down to their level, then beat you with experience.
On Mon, 28 Jan 2002, Ingo Molnar wrote:
> On Mon, 28 Jan 2002, Martin Josefsson wrote:
>
> > > - spin_unlock_irq(&rq->lock);
> > > + spin_unlock(&rq->lock);
>
> > I'm not an spinlock expert but shouldn't you use spin_unlock_irq()
> > when it was locked with spin_lock_irq() ?
>
> normally yes, but in this case it's an optimization: schedule() will
> disable interrupts within a few cycles, so there is no point in enabling
> irqs for a short amount of time.
Needs a comment.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Mon, 28 Jan 2002, Oliver Xymoron wrote:
> > > > - spin_unlock_irq(&rq->lock);
> > > > + spin_unlock(&rq->lock);
> > normally yes, but in this case it's an optimization: schedule() will
> > disable interrupts within a few cycles, so there is no point in enabling
> > irqs for a short amount of time.
> Needs a comment.
agreed, John Levon suggested this too. I've added a comment to my tree,
should show up in the next patches.
Ingo
Ingo Molnar <[email protected]> said:
> On Mon, 28 Jan 2002, Martin Josefsson wrote:
>
> > > - spin_unlock_irq(&rq->lock);
> > > + spin_unlock(&rq->lock);
>
> > I'm not an spinlock expert but shouldn't you use spin_unlock_irq()
> > when it was locked with spin_lock_irq() ?
>
> normally yes, but in this case it's an optimization: schedule() will
> disable interrupts within a few cycles, so there is no point in enabling
> irqs for a short amount of time.
And a short comment in the code?
--
Horst von Brand http://counter.li.org # 22616