From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/3] broadcast-tick: Move oneshot broadcast mask to per cpu variables v2
Date: Tue, 6 Sep 2011 17:28:57 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.02.1109061704330.2723@ionos> (raw)
In-Reply-To: <1314652136-11350-2-git-send-email-andi@firstfloor.org>
On Mon, 29 Aug 2011, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Avoid a global cache line hotspot in the oneshot cpu mask. Maintain
> this information in per cpu variables instead.
<SNIP>
> @@ -411,7 +418,9 @@ again:
> cpumask_clear(to_cpumask(tmpmask));
> now = ktime_get();
> /* Find all expired events */
> - for_each_cpu(cpu, tick_get_broadcast_oneshot_mask()) {
> + for_each_online_cpu(cpu) {
> + if (!per_cpu(state, cpu).need_oneshot)
> + continue;
So we iterate over each online CPU instead. I'm really not convinced
that this is better performing especially if the number of CPUs in
broadcast mode is way smaller than the number of online CPUs.
Also having a separate per cpu variable which is just a boolean marker
is silly. If we really want move that to per cpu storage then the
marker should simply be the expiry time of that CPU so you don't have
to evaluate two per cpu variables, which are in completely different
cachelines. If a CPU is not in that mode that expiry time should
simply read KTIME_MAX.
But again, I'm not convinced that iterating over a large number of
CPUs to find a single one in oneshot mode is a good idea.
Thanks,
tglx
next prev parent reply other threads:[~2011-09-06 15:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 21:08 [PATCH 1/3] clockevents: Use an atomic RCU notifier for clockevents Andi Kleen
2011-08-29 21:08 ` [PATCH 2/3] broadcast-tick: Move oneshot broadcast mask to per cpu variables v2 Andi Kleen
2011-09-06 15:28 ` Thomas Gleixner [this message]
2011-08-29 21:08 ` [PATCH 3/3] tick-broadcast: push down tick_broadcast_lock Andi Kleen
2011-09-06 16:19 ` Thomas Gleixner
2011-09-06 17:49 ` Andi Kleen
2011-09-06 18:55 ` Thomas Gleixner
2011-09-06 19:23 ` [PATCH 1/3] clockevents: Use an atomic RCU notifier for clockevents Thomas Gleixner
2011-09-06 20:33 ` Andi Kleen
2011-09-06 21:45 ` Thomas Gleixner
2011-09-06 22:42 ` Andi Kleen
2011-09-06 23:19 ` Thomas Gleixner
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.1109061704330.2723@ionos \
--to=tglx@linutronix.de \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@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
Powered by JetHome