From: Paul Clarke <pc@us.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@lists.ozlabs.org
Subject: Re: powerpc: mitigate impact of decrementer reset
Date: Wed, 05 Nov 2014 11:06:39 -0600 [thread overview]
Message-ID: <545A591F.3080400@us.ibm.com> (raw)
In-Reply-To: <20141008025210.AF949140144@ozlabs.org>
Sorry it took me so long to get back to this...
On 10/07/2014 09:52 PM, Michael Ellerman wrote:
> On Tue, 2014-07-10 at 19:13:24 UTC, Paul Clarke wrote:
>> The POWER ISA defines an always-running decrementer which can be used
>> to schedule interrupts after a certain time interval has elapsed.
>> The decrementer counts down at the same frequency as the Time Base,
>> which is 512 MHz. The maximum value of the decrementer is 0x7fffffff.
>> This works out to a maximum interval of about 4.19 seconds.
>>
>> If a larger interval is desired, the kernel will set the decrementer
>> to its maximum value and reset it after it expires (underflows)
>> a sufficient number of times until the desired interval has elapsed.
>>
>> The negative effect of this is that an unwanted latency spike will
>> impact normal processing at most every 4.19 seconds. On an IBM
>> POWER8-based system, this spike was measured at about 25-30
>> microseconds, much of which was basic, opportunistic housekeeping
>> tasks that could otherwise have waited.
>>
>> This patch short-circuits the reset of the decrementer, exiting after
>> the decrementer reset, but before the housekeeping tasks if the only
>> need for the interrupt is simply to reset it. After this patch,
>> the latency spike was measured at about 150 nanoseconds.
> Thanks for the excellent changelog. But this patch makes me a bit nervous :)
>
> Do you know where the latency is coming from? Is it primarily the irq work?
Yes, it is all under irq_enter (measured at ~10us) and irq_exit (~12us).
> If so I'd prefer if we could move the short circuit into __timer_interrupt()
> itself. That way we'd still have the trace points usable, and it would
> hopefully result in less duplicated logic.
But irq_enter and irq_exit are called in timer_interrupt, before
__timer_interrupt is called. I don't see how that helps. The time
spent in __timer_interrupt is minuscule by comparison.
Are you suggesting that irq_enter/exit be moved into __timer_interrupt
as well? (I'm not sure how that would impact the existing call to
__timer_interrupt from tick_broadcast_ipi_handler? And if there is no
impact, what's the point of separating timer_interrupt and
__timer_interrupt?)
Regards,
PC
next prev parent reply other threads:[~2014-11-05 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1412708517-84726-1-git-send-email-pc@us.ibm.com>
2014-10-07 19:13 ` [PATCH] powerpc: mitigate impact of decrementer reset Paul Clarke
2014-10-08 2:52 ` Michael Ellerman
2014-10-08 10:27 ` Preeti U Murthy
2014-11-05 17:06 ` Paul Clarke [this message]
2014-11-13 2:39 ` Michael Ellerman
2014-11-13 19:33 ` Paul Clarke
2014-10-08 5:37 ` [PATCH] " Heinz Wrobel
2014-10-08 12:27 ` Paul Clarke
2014-11-10 10:08 ` Benjamin Herrenschmidt
2014-11-10 20:58 ` Paul Clarke
2014-11-13 2:42 ` Michael Ellerman
2014-11-17 19:18 ` Paul E. McKenney
2014-11-18 1:46 ` Michael Ellerman
2014-11-18 3:08 ` Paul E. McKenney
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=545A591F.3080400@us.ibm.com \
--to=pc@us.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.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 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.