All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.