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

Nick Piggin wrote:
> Ingo Molnar wrote:
> 
>> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>> Oh, I forgot: Ingo once introduced some code to bail early (though 
>>> for different reasons and under different conditions), and this 
>>> actually was found to cause significant regressions in some database 
>>> workloads.
>>
>>
>>
>> well, we both did changes with that effect - pretty much any change in 
>> this area can cause a regression on _some_ workload ;) So there wont 
>> be any silver bullet.
>>
> 
> Well yes. Although specifically the bail-out-early stuff which IIRC
> you did... I wasn't singling you out in particular, I've broken the
> scheduler at _least_ as much as you have since starting work on it ;)
> 

... and my point is that there is not much reason to introduce a
possible performance regression because of such a latency in an
artificial test case, especially when there are other sources of
unbound latency when dealing with large numbers of tasks (and on
uniprocessor too, eg. rwsem).

However, as an RT-tree thing obviously I have no problems with it,
but unless your interrupt thread is preemptible, then there isn't
much point because it can cause a similar latency (that your tools
won't detect) simply by running multiple times.

You really want isolcpus on SMP machines to really ensure load
balancing doesn't harm RT behaviour, yeah?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2006-02-01 13:54 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
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 [this message]
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=43E0BDA3.8040003@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pwil3058@bigpond.net.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