From: Ingo Molnar <mingo@elte.hu>
To: Mike Travis <travis@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jack Steiner <steiner@sgi.com>,
linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/6] x86_64 UV: Use blinking LED for heartbeat display
Date: Mon, 11 Aug 2008 18:02:35 +0200 [thread overview]
Message-ID: <20080811160235.GC4524@elte.hu> (raw)
In-Reply-To: <20080808005652.543469000@polaris-admin.engr.sgi.com>
* Mike Travis <travis@sgi.com> wrote:
> +#ifdef CONFIG_CLOCKSOURCE_WATCHDOG
> +static void uv_display_heartbeat(void)
> +{
> + int cpu;
> +
> + uv_hub_info->led_heartbeat_count = nr_cpu_ids;
> +
> + for_each_online_cpu(cpu) {
> + struct uv_hub_info_s *hub = uv_cpu_hub_info(cpu);
> +
> + if (hub->led_heartbeat_count > 0) {
> + uv_set_led_bits_on(cpu, LED_CPU_BLINK,
> + LED_CPU_HEARTBEAT);
> + --hub->led_heartbeat_count;
> + }
this too is a bad idea. Imagine 16K cores and assume that each such
iteration takes a few usecs (we write cross CPU) and you've got a
GHz-ish CPU. That can easily be _milliseconds_ of delay (or more) - and
in a function (the clocksource watchdog) that is all about precise
timings.
It is also very non-preemptable.
Why not have a separate per cpu kthread for this that does this in a
preemptable manner?
Also, why not let each CPU's heartbeat be set in a hierarchy instead of
by _all_ CPUs. That way you get a nice constant-ish overhead instead of
the current crazy quadratic(nr_cpus) behavior. I.e. let each CPU be
monitored by its neighbor (cpu_id + 1), by it's second-order neighbor
(cpu_id + 2), third-order neighbor (cpu_id + 4), etc.
That still gives pretty good coverage in practice while avoiding the
quadratic nature.
Ingo
next prev parent reply other threads:[~2008-08-11 16:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-08 0:56 [PATCH 0/6] SGI UV: Provide a LED driver and some System Activity Indicators Mike Travis
2008-08-08 0:56 ` [PATCH 1/6] x86_64 UV: Provide a LED driver for UV Systems Mike Travis
2008-08-08 0:56 ` [PATCH 2/6] x86_64 UV: Use LED to indicate CPU is active Mike Travis
2008-08-11 15:53 ` Ingo Molnar
2008-08-13 9:56 ` Pavel Machek
2008-08-25 17:53 ` Mike Travis
2008-08-25 17:49 ` Mike Travis
2008-08-08 0:56 ` [PATCH 3/6] x86_64 UV: Use blinking LED for heartbeat display Mike Travis
2008-08-11 16:02 ` Ingo Molnar [this message]
2008-08-13 9:57 ` Pavel Machek
2008-08-26 20:53 ` Mike Travis
2008-08-27 21:38 ` Pavel Machek
2008-08-25 17:55 ` Mike Travis
2008-08-08 0:56 ` [PATCH 4/6] ia64 UV: Provide a LED driver for UV Systems Mike Travis
2008-08-08 6:07 ` Andrew Morton
2008-08-08 0:56 ` [PATCH 5/6] ia64 UV: Use LED to indicate CPU is active Mike Travis
2008-08-08 0:56 ` [PATCH 6/6] ia64 UV: Use blinking LED for heartbeat display Mike Travis
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=20080811160235.GC4524@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=travis@sgi.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