public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] sched: minor optimization
  2007-11-24 11:46 Nikanth Karthikesan
@ 2007-11-23 12:18 ` Dmitry Adamushko
  0 siblings, 0 replies; 3+ messages in thread
From: Dmitry Adamushko @ 2007-11-23 12:18 UTC (permalink / raw)
  To: Nikanth Karthikesan; +Cc: mingo, a.p.zijlstra, linux-kernel, vatsa

On 24/11/2007, Nikanth Karthikesan <knikanth@suse.de> wrote:
> As an optimization, if all tasks are in the fair class, the next task is
> directly picked from fair_sched_class. But, if it returns no task we go
> through again from sched_class_highest which could be avoided and
> instead return the idle task directly.

The only legitimate possibility of having the fair_sched_class
returning no task in this case is when 'rq->nr_running ==
rq->cfs.nr_running == 0'.

iow, a possible optimization would be just the following check :

if (rq->nr_running == 0)
        return idle_sched_class.pick_next_task(rq);

at the beginning of pick_next_task().

(or maybe put it at the beginning of the
if (likely(rq->nr_running == rq->cfs.nr_running)) {} block as we
already have 'likely()' there).


-- 
Best regards,
Dmitry Adamushko

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] sched: minor optimization
@ 2007-11-24 11:46 Nikanth Karthikesan
  2007-11-23 12:18 ` Dmitry Adamushko
  0 siblings, 1 reply; 3+ messages in thread
From: Nikanth Karthikesan @ 2007-11-24 11:46 UTC (permalink / raw)
  To: mingo; +Cc: dmitry.adamushko, a.p.zijlstra, linux-kernel, vatsa

As an optimization, if all tasks are in the fair class, the next task is
directly picked from fair_sched_class. But, if it returns no task we go
through again from sched_class_highest which could be avoided and
instead return the idle task directly.


Signed-off-by : Nikanth Karthikesan <knikanth@suse.de>
---
 kernel/sched.c |    2 ++
 1 file changed, 2 insertions(+)

Index: b/kernel/sched.c
===================================================================
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3449,6 +3449,8 @@ pick_next_task(struct rq *rq, struct tas
 		p = fair_sched_class.pick_next_task(rq);
 		if (likely(p))
 			return p;
+		else /* rq->nr_running is zero */
+			return idle_sched_class.pick_next_task(rq);
 	}

 	class = sched_class_highest;

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] sched: minor optimization
@ 2007-11-24 13:26 Nikanth Karthikesan
  0 siblings, 0 replies; 3+ messages in thread
From: Nikanth Karthikesan @ 2007-11-24 13:26 UTC (permalink / raw)
  To: Dmitry Adamushko; +Cc: a.p.zijlstra, linux-kernel, vatsa, mingo

> On Fri, Nov 23, 2007 at  5:48 PM, "Dmitry Adamushko"
<dmitry.adamushko@gmail.com> wrote:
> The only legitimate possibility of having the fair_sched_class
> returning no task in this case is when 'rq->nr_running ==
> rq->cfs.nr_running == 0'.

Yes, I think so.

> iow, a possible optimization would be just the following check :
>
> if (rq->nr_running == 0)
>         return idle_sched_class.pick_next_task(rq);
> at the beginning of pick_next_task().
>
> (or maybe put it at the beginning of the
> if (likely(rq->nr_running == rq->cfs.nr_running)) {} block as we
> already have 'likely()' there).
>

But that might add a test before the case we want to optimize the most.
I just thought of taking advantage of a case where we know
rq->nr_running==0, instead of throwing away that information.

Thanks
Nikanth

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-11-23 13:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-24 13:26 [PATCH] sched: minor optimization Nikanth Karthikesan
  -- strict thread matches above, loose matches on Subject: below --
2007-11-24 11:46 Nikanth Karthikesan
2007-11-23 12:18 ` Dmitry Adamushko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox