public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Mike Galbraith <efault@gmx.de>
Cc: lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@osdl.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Con Kolivas <kernel@kolivas.org>
Subject: Re: [2.6.16-mm1 patch] throttling tree patches
Date: Sat, 25 Mar 2006 11:37:32 +1100	[thread overview]
Message-ID: <442490CC.8090200@bigpond.net.au> (raw)
In-Reply-To: <1143198208.7741.8.camel@homer>

Mike Galbraith wrote:
> Greetings,
> 
> I've broken down my throttling tree into 6 patches, which I'll send as
> replies to this start-point.
> 
> Patch 1/6
> 
> Ignore timewarps caused by SMP timestamp rounding.  Also, don't stamp a
> task with a computed timestamp, stamp with the already called clock.
> 
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> 
> --- linux-2.6.16-mm1/kernel/sched.c.org	2006-03-23 15:01:41.000000000 +0100
> +++ linux-2.6.16-mm1/kernel/sched.c	2006-03-23 15:02:25.000000000 +0100
> @@ -805,6 +805,16 @@
>  	unsigned long long __sleep_time = now - p->timestamp;
>  	unsigned long sleep_time;
>  
> +	/*
> +	 * On SMP systems, a task can go to sleep on one CPU and
> +	 * wake up on another.  When this happens, the timestamp
> +	 * is rounded to the nearest tick,

Is this true?  There's no rounding that I can see.  An attempt is made 
to adjust the timestamp for the drift between time as seen from the two 
CPUs but there's no deliberate rounding involved.  Of course, that's not 
to say that the adjustment is accurate as I'm not convinced that the 
difference between the run queues' timestamp_last_tick is a always 
totally accurate measure of the drift in their clocks (due to possible 
races -- I may be wrong).

Of course, that doesn't mean that this chunk of code isn't required just 
that the comment is misleading.

> which can lead to now
> +	 * being less than p->timestamp for short sleeps. Ignore
> +	 * these, they're insignificant.
> +	 */
> +	if (unlikely(now < p->timestamp))
> +		__sleep_time = 0ULL;
> +
>  	if (batch_task(p))
>  		sleep_time = 0;
>  	else {
> @@ -871,20 +881,20 @@
>   */
>  static void activate_task(task_t *p, runqueue_t *rq, int local)
>  {
> -	unsigned long long now;
> +	unsigned long long now, comp;
>  
> -	now = sched_clock();
> +	now = comp = sched_clock();
>  #ifdef CONFIG_SMP
>  	if (!local) {
>  		/* Compensate for drifting sched_clock */
>  		runqueue_t *this_rq = this_rq();
> -		now = (now - this_rq->timestamp_last_tick)
> +		comp = (now - this_rq->timestamp_last_tick)
>  			+ rq->timestamp_last_tick;
>  	}
>  #endif
>  
>  	if (!rt_task(p))
> -		p->prio = recalc_task_prio(p, now);
> +		p->prio = recalc_task_prio(p, comp);
>  
>  	/*
>  	 * This checks to make sure it's not an uninterruptible task

I think that this will end up with p->timestamp being set with a time 
appropriate to the current task's CPU rather than its own.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

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

  parent reply	other threads:[~2006-03-25  0:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24 11:03 [2.6.16-mm1 patch] throttling tree patches Mike Galbraith
2006-03-24 11:07 ` Mike Galbraith
2006-03-24 11:16   ` Mike Galbraith
2006-03-24 11:21     ` Mike Galbraith
2006-03-24 11:24       ` Mike Galbraith
2006-03-24 11:28         ` Mike Galbraith
2006-03-24 11:56           ` Con Kolivas
2006-03-24 11:55         ` Con Kolivas
2006-03-24 11:54       ` Con Kolivas
2006-03-24 11:56     ` Con Kolivas
2006-03-24 12:21       ` Mike Galbraith
2006-03-24 12:34         ` Con Kolivas
2006-03-24 13:02           ` Mike Galbraith
2006-03-24 13:52             ` Con Kolivas
2006-03-24 14:10               ` Mike Galbraith
2006-03-24 11:38   ` Con Kolivas
2006-03-24 11:37 ` Con Kolivas
2006-03-25  0:25   ` Peter Williams
2006-03-25  5:06     ` Mike Galbraith
2006-03-25  6:18       ` [2.6.16-mm1 patch] ignore timewarps Mike Galbraith
2006-03-25  0:37 ` Peter Williams [this message]
2006-03-25  5:11   ` [2.6.16-mm1 patch] throttling tree patches Mike Galbraith

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=442490CC.8090200@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    /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