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
next prev parent 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).