linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 1/4] tickless idle cpu - Allow any CPU to update jiffies
Date: Mon, 10 Apr 2006 17:19:44 +0530	[thread overview]
Message-ID: <20060410114944.GA5564@in.ibm.com> (raw)
In-Reply-To: <17462.61423.42032.559627@cargo.ozlabs.ibm.com>

On Sat, Apr 08, 2006 at 09:04:15AM +1000, Paul Mackerras wrote:
> Srivatsa Vaddagiri writes:
> 
> > Currently, only boot CPU calls do_timer to update jiffies. This prevents
> > idle boot CPU from skipping ticks. Patch below, against 2.6.17-rc1-mm1,
> > allows jiffies to be updated from any CPU.
> 
> We have to be very careful here.  The code that keeps xtime and
> gettimeofday in sync relies on xtime being incremented as close as
> possible in time to when the timebase passes specific values.  Since
> we currently stagger the timer interrupts for the cpus throughout a
> jiffy, having cpus other than the boot cpus calling do_timer will
> break this and introduce inaccuracies.  There are also implications
> for the stolen time accounting on shared-processor LPAR systems.
> 
> I think we need to remove the staggering, thus having all cpus take
> their timer interrupt at the same time.  That way, any of them can
> call do_timer.  However we then have to be much more careful about
> possible contention, e.g. on xtime_lock.  Your patch has every cpu
> taking xtime_lock for writing rather than just the boot cpu.  I'd like
> to see if there is some way to avoid that (while still having just one
> cpu call do_timer, of course).

Paul,
	Thanks for the feedback on the patches.

Avoiding contention on xtime_lock doesnt seem to be trivial. Any
solution to it is fraught with races. Anyway, I have attempted one
solution (in the followon Patch 2/2) which keeps the overhead in timer 
interrupt handler low. 

Let me know if you have other suggestions to avoid xtime_lock
contention!

Following patches are sent in separate mails:

Patch 1/2	-	Core patch to skip ticks - v2
Patch 2/2	- 	Allow boot CPU to skip ticks - v2

The sysctl control patch and decrementer statistics patch are as before
and hence I am not resending them this time.


-- 
Regards,
vatsa

  reply	other threads:[~2006-04-10 11:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07  6:30 [PATCH 1/4] tickless idle cpu - Allow any CPU to update jiffies Srivatsa Vaddagiri
2006-04-07 23:04 ` Paul Mackerras
2006-04-10 11:49   ` Srivatsa Vaddagiri [this message]
2006-04-10 12:18   ` [PATCH 1/2] tickless idle cpus: core patch - v2 Srivatsa Vaddagiri
2006-04-11 17:35     ` Paul Mackerras
2006-04-12  4:50       ` Srivatsa Vaddagiri
2006-04-21 10:49     ` Paul Mackerras
2006-04-24 15:39       ` Srivatsa Vaddagiri
2006-04-10 12:19   ` [PATCH 2/2] tickless idle cpus: allow boot cpu to skip ticks Srivatsa Vaddagiri

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=20060410114944.GA5564@in.ibm.com \
    --to=vatsa@in.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /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;
as well as URLs for NNTP newsgroup(s).