public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] Avoid moving tasks when a schedule can be made.
Date: Wed, 01 Feb 2006 14:36:34 +1100	[thread overview]
Message-ID: <43E02CC2.3080805@bigpond.net.au> (raw)
In-Reply-To: <1138736609.7088.35.camel@localhost.localdomain>

Steven Rostedt wrote:
> I found this in the -rt kernel.  While running "hackbench 20" I hit
> latencies of over 1.5 ms.  That is huge!  This latency was created by
> the move_tasks function in sched.c to rebalance the queues over CPUS.  
> 
> There currently isn't any check in this function to see if it should
> stop, thus a large number of tasks can drive the latency high.
> 
> With the below patch, (tested on -rt with latency tracing), the latency
> caused by hackbench disappeared below my notice threshold (100 usecs).
> 
> I'm not convinced that this bail out is in the right location, but it
> worked where it is.  Comments are welcome.
> 
> -- Steve
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
> Index: linux-2.6.16-rc1/kernel/sched.c
> ===================================================================
> --- linux-2.6.16-rc1.orig/kernel/sched.c	2006-01-19 15:58:52.000000000 -0500
> +++ linux-2.6.16-rc1/kernel/sched.c	2006-01-31 14:27:17.000000000 -0500
> @@ -1983,6 +1983,10 @@
>  
>  	curr = curr->prev;
>  
> +	/* bail if someone else woke up */
> +	if (need_resched())
> +		goto out;
> +
>  	if (!can_migrate_task(tmp, busiest, this_cpu, sd, idle, &pinned)) {
>  		if (curr != head)
>  			goto skip_queue;
> 

I presume that the intention here is to allow a newly woken task that 
preempts the current task to stop the load balancing?

As I see it (and I may be wrong), for this to happen, the task must have 
woken before the run queue locks were taken (otherwise it wouldn't have 
got as far as activation) i.e. before move_tasks() is called and 
therefore you may as well just do this check at the start of move_tasks().

However, a newly woken task that preempts the current task isn't the 
only way that needs_resched() can become true just before load balancing 
is started.  E.g. scheduler_tick() calls set_tsk_need_resched(p) when a 
task finishes a time slice and this patch would cause rebalance_tick() 
to be aborted after a lot of work has been done in this case.

In summary, I think that the bail out is badly placed and needs some way 
of knowing if the reason need_resched() has become true is because of 
preemption of a newly woken task and not some other reason.

Peter
PS I've added Nick Piggin to the CC list as he is interested in load 
balancing issues.
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-02-01  3:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-31 19:43 [PATCH] Avoid moving tasks when a schedule can be made Steven Rostedt
2006-02-01  3:36 ` Peter Williams [this message]
2006-02-01 12:44   ` Steven Rostedt
2006-02-01 13:06     ` Nick Piggin
2006-02-01 13:10       ` Nick Piggin
2006-02-01 13:20         ` Ingo Molnar
2006-02-01 13:47           ` Nick Piggin
2006-02-01 13:54             ` Nick Piggin
2006-02-01 14:12               ` Ingo Molnar
2006-02-01 14:25                 ` Nick Piggin
2006-02-01 14:37                   ` Ingo Molnar
2006-02-01 14:54                     ` Nick Piggin
2006-02-01 15:11                       ` Ingo Molnar
2006-02-01 15:31                         ` Nick Piggin
2006-02-01 16:10                           ` Ingo Molnar
2006-02-01 16:25                             ` Nick Piggin
2006-02-01 17:24                               ` Ingo Molnar
2006-02-06 11:21                                 ` Nick Piggin
2006-02-01 14:00             ` Ingo Molnar
2006-02-01 14:09               ` Nick Piggin
2006-02-01 14:22                 ` Ingo Molnar
2006-02-01 14:32                   ` Steven Rostedt
2006-02-02  1:26     ` Peter Williams
2006-02-02  2:48       ` Steven Rostedt
2006-02-02  3:19         ` Peter Williams
2006-02-01 13:08 ` Ingo Molnar
2006-02-01 13:11   ` Ingo Molnar
2006-02-02  1:42     ` Peter Williams
2006-02-02  2:51       ` Steven Rostedt
2006-02-01 13:15   ` Steven Rostedt
2006-02-01 13:23   ` Steven Rostedt
2006-02-01 13:26     ` Ingo Molnar
2006-02-01 16:11       ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43E02CC2.3080805@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox