From: Andi Kleen <ak@muc.de>
To: Tony Lindgren <tony@atomide.com>
Cc: vatsa@in.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Dynamic tick for x86 version 050609-2
Date: 13 Jun 2005 20:51:09 +0200
Date: Mon, 13 Jun 2005 20:51:09 +0200 [thread overview]
Message-ID: <20050613185109.GA86745@muc.de> (raw)
In-Reply-To: <20050613183716.GH8020@atomide.com>
On Mon, Jun 13, 2005 at 11:37:16AM -0700, Tony Lindgren wrote:
> * Andi Kleen <ak@muc.de> [050613 10:57]:
> > Srivatsa Vaddagiri <vatsa@in.ibm.com> writes:
> > >
> > > 2. reprogram_apic_timer seems to reprogram the count-down
> > > APIC timer (APIC_TMICT) with an integral number of apic_timer_val.
> > > How accurate will this be? Shouldnt this take into account
> > > that we may not be reprogramming the timer on exactly "jiffy"
> > > boundary?
> >
> > All PIT based reprogramming schemes will lose time.
>
> Not true if the timesource is different from interrupt source.
>
> Consider PM timer for timesource, and PIT for interrupt source. Reprogamming
> PIT should not affect PM timer. Time is always updated from PM timer.
PM timer is not really suitable for this because it overflows
too quickly (several times a second).
Also you still lose time in timers (e.g. your internal timers slowly drift)
unless you regularly sync with the time source, but that has other
drawbacks.
> >
> > Actually there is a small reason - RCU currently does not get
> > updated by a fully idle CPU and can stall other CPUs. But that is in
> > practice not too big an issue yet because so many subsystems
> > cause ticks now and then, so the CPUs tend to wake up often
> > enough to not stall the rest of the system too badly.
>
> I guess it should be safe to reprogram timer even if other CPUs are not
> idle, assuming the busy CPUs reprogramming timer will also wake up the idle
> CPUs.
>
> There's one thing that should be considered though; Reprogamming
> timers should be avoided if the system is busy as it causes
> performance issues. Especially reprogramming PIT.
Just forget about reprogramming with PIT. IMHO that should
be never used in production. The right way for this
is HPET.
The main issue with HPET is that many BIOS even though the chipsets
have it don't set up the HPET table because Windows doesn't use
it right now. However that can be avoided with some chipset
specific code.
-Andi
next prev parent reply other threads:[~2005-06-13 18:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-08 22:14 [PATCH] Dynamic tick for x86 version 050602-1 Pallipadi, Venkatesh
2005-06-09 1:40 ` Tony Lindgren
2005-06-10 4:30 ` [PATCH] Dynamic tick for x86 version 050609-2 Tony Lindgren
2005-06-10 9:10 ` Pavel Machek
2005-06-10 15:10 ` Tony Lindgren
2005-06-13 4:54 ` Valdis.Kletnieks
2005-06-13 15:25 ` Tony Lindgren
2005-06-13 16:47 ` Valdis.Kletnieks
2005-06-13 18:01 ` Thomas Renninger
2005-06-13 18:22 ` Tony Lindgren
2005-06-13 19:07 ` Valdis.Kletnieks
2005-06-14 9:39 ` Thomas Renninger
2005-06-14 15:40 ` Valdis.Kletnieks
2005-06-13 17:09 ` Srivatsa Vaddagiri
2005-06-13 17:55 ` Andi Kleen
2005-06-13 18:37 ` Tony Lindgren
2005-06-13 18:51 ` Andi Kleen [this message]
2005-06-13 19:35 ` Tony Lindgren
2005-06-13 19:48 ` Valdis.Kletnieks
2005-06-13 18:27 ` Tony Lindgren
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=20050613185109.GA86745@muc.de \
--to=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@atomide.com \
--cc=vatsa@in.ibm.com \
/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