From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 4/7] tick: Handle broadcast wakeup of multiple cpus
Date: Wed, 13 Mar 2013 22:42:15 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1303132239510.22263@ionos> (raw)
In-Reply-To: <20130313113623.GA6635@e102568-lin.cambridge.arm.com>
On Wed, 13 Mar 2013, Lorenzo Pieralisi wrote:
> > + /* Take care of enforced broadcast requests */
> > + cpumask_or(tmpmask, tmpmask, tick_broadcast_force_mask);
> > + cpumask_clear(tick_broadcast_force_mask);
>
> I tested the set and it works fine on a dual cluster big.LITTLE testchip
> using broadcast timer to manage deep idle cluster states.
>
> Just asking a question: the force mask is cleared before sending the
> timer IPI. Would not be better to clear it after the IPI is sent in
>
> tick_do_broadcast(...) ?
>
> Can you spot a regression if we do this ? The idle thread checks that
> mask with irqs disabled, so it is possible that we clear the mask before
> the CPU has a chance to get the IPI. If we clear the mask after sending
> the IPI, we are increasing the chances for the idle thread to get it.
>
> It is just a further optimization, just asking, thanks.
Need to think about that.
> > @@ -524,7 +530,16 @@ void tick_broadcast_oneshot_control(unsi
> > WARN_ON_ONCE(cpumask_test_cpu(cpu, tick_broadcast_pending_mask));
> > if (!cpumask_test_and_set_cpu(cpu, tick_broadcast_oneshot_mask)) {
> > clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
> > - if (dev->next_event.tv64 < bc->next_event.tv64)
> > + /*
> > + * We only reprogram the broadcast timer if we
> > + * did not mark ourself in the force mask and
> > + * if the cpu local event is earlier than the
> > + * broadcast event. If the current CPU is in
> > + * the force mask, then we are going to be
> > + * woken by the IPI right away.
> > + */
> > + if (!cpumask_test_cpu(cpu, tick_broadcast_force_mask) &&
> Is the test against tick_broadcast_force_mask necessary if we add the check
> in the idle thread before entering idle ? It does not hurt, agreed, and we'd
> better leave it there, it is just for my own understanding, thanks a lot.
Well, it's necessary for all archs which do not have the check (yet).
> Having said that, on the series:
>
> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Thanks,
tglx
next prev parent reply other threads:[~2013-03-13 21:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 11:18 [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong Thomas Gleixner
2013-03-06 11:18 ` [patch 1/7] tick: Call tick_init late Thomas Gleixner
2013-03-06 11:18 ` [patch 2/7] tick: Convert broadcast cpu bitmaps to cpumask_var_t Thomas Gleixner
2013-03-07 5:51 ` Rusty Russell
2013-03-06 11:18 ` [patch 3/7] tick: Avoid programming the local cpu timer if broadcast pending Thomas Gleixner
2013-03-06 11:18 ` [patch 4/7] tick: Handle broadcast wakeup of multiple cpus Thomas Gleixner
2013-03-13 11:36 ` Lorenzo Pieralisi
2013-03-13 21:42 ` Thomas Gleixner [this message]
2013-03-06 11:18 ` [patch 5/7] tick: Provide a check for a forced broadcast pending Thomas Gleixner
2013-03-06 11:18 ` [patch 7/7] x86: Use tick broadcast expired check Thomas Gleixner
2013-03-06 11:18 ` [patch 6/7] arm: " Thomas Gleixner
2013-03-13 9:35 ` [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong Santosh Shilimkar
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=alpine.LFD.2.02.1303132239510.22263@ionos \
--to=tglx@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.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).