From: Thomas Gleixner <tglx@linutronix.de> To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: LKML <linux-kernel@vger.kernel.org>, LAK <linux-arm-kernel@lists.infradead.org>, John Stultz <john.stultz@linaro.org>, Arjan van de Veen <arjan@infradead.org>, Santosh Shilimkar <santosh.shilimkar@ti.com>, Jason Liu <liu.h.jason@gmail.com> Subject: Re: [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
WARNING: multiple messages have this Message-ID (diff)
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: 31+ 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 ` Thomas Gleixner 2013-03-06 11:18 ` [patch 1/7] tick: Call tick_init late Thomas Gleixner 2013-03-06 11:18 ` Thomas Gleixner 2013-03-07 16:29 ` [tip:timers/core] " tip-bot for Thomas Gleixner 2013-03-06 11:18 ` [patch 2/7] tick: Convert broadcast cpu bitmaps to cpumask_var_t Thomas Gleixner 2013-03-06 11:18 ` Thomas Gleixner 2013-03-07 5:51 ` Rusty Russell 2013-03-07 5:51 ` Rusty Russell 2013-03-07 16:30 ` [tip:timers/core] " tip-bot for Thomas Gleixner 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 ` Thomas Gleixner 2013-03-19 11:35 ` [tip:timers/core] " tip-bot for Thomas Gleixner 2013-03-06 11:18 ` [patch 4/7] tick: Handle broadcast wakeup of multiple cpus Thomas Gleixner 2013-03-06 11:18 ` Thomas Gleixner 2013-03-13 11:36 ` Lorenzo Pieralisi 2013-03-13 11:36 ` Lorenzo Pieralisi 2013-03-13 21:42 ` Thomas Gleixner [this message] 2013-03-13 21:42 ` Thomas Gleixner 2013-03-19 11:37 ` [tip:timers/core] " tip-bot for Thomas Gleixner 2013-03-06 11:18 ` [patch 5/7] tick: Provide a check for a forced broadcast pending Thomas Gleixner 2013-03-06 11:18 ` Thomas Gleixner 2013-03-19 11:38 ` [tip:timers/core] " tip-bot for Thomas Gleixner 2013-03-06 11:18 ` [patch 6/7] arm: Use tick broadcast expired check Thomas Gleixner 2013-03-06 11:18 ` Thomas Gleixner 2013-03-19 11:39 ` [tip:timers/core] " tip-bot for Thomas Gleixner 2013-03-06 11:18 ` [patch 7/7] x86: " Thomas Gleixner 2013-03-06 11:18 ` Thomas Gleixner 2013-03-19 11:40 ` [tip:timers/core] " tip-bot for Thomas Gleixner 2013-03-13 9:35 ` [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong Santosh Shilimkar 2013-03-13 9:35 ` 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=arjan@infradead.org \ --cc=john.stultz@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=liu.h.jason@gmail.com \ --cc=lorenzo.pieralisi@arm.com \ --cc=santosh.shilimkar@ti.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: linkBe 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.