From: Nathan Lynch <ntl@pobox.com>
To: Sebastien Dugue <sebastien.dugue@bull.net>
Cc: Dion <jean-pierre.dion@bull.net>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Will Schmidt <will_schmidt@vnet.ibm.com>,
Gilles Carry <Gilles.Carry@ext.bull.net>,
Paul Mackerras <paulus@samba.org>,
Jean
Subject: Re: [PATCH] powerpc/pseries: Fix cpu hotplug
Date: Thu, 27 Nov 2008 18:14:33 -0600 [thread overview]
Message-ID: <20081128001433.GI6830@localdomain> (raw)
In-Reply-To: <20081127115952.1f7db89d@bull.net>
Hi, I have some questions about this patch.
Sebastien Dugue wrote:
>
> Currently, pseries_cpu_die() calls msleep() while polling RTAS for
> the status of the dying cpu.
>
> However if the cpu that is going down also happens to be the one doing
> the tick then we're hosed as the tick_do_timer_cpu 'baton' is only passed
> later on in tick_shutdown() when _cpu_down() does the CPU_DEAD notification.
> Therefore jiffies won't be updated anymore.
I confess unfamiliarity with the tick/timer code, but this sounds like
something that should be addressed earlier in the process of taking
down a CPU.
> This patch replaces that msleep() with a cpu_relax() to make sure we're
> not going to schedule at that point.
This is a significant change in behavior. With the msleep(), we poll
for at least five seconds before giving up; with the cpu_relax(), the
period will almost certainly be much shorter and we're likely to give
up too soon in some circumstances. Could be addressed by using
mdelay(), but...
It's just not clear to me how busy-waiting in the __cpu_die() path is
a legitimate fix. Is sleeping in this path forbidden now? (I notice
at least native_cpu_die() in x86 does msleep(), btw.)
As it can take several milliseconds for RTAS to report a CPU
offline, and the maximum latency of the operation is unspecified, it
seems inappropriate to tie up the waiting CPU this way.
> With this patch my test box survives a 100k iterations hotplug stress
> test on _all_ cpus, whereas without it, it quickly dies after ~50 iterations.
What is the failure (e.g. stack trace, kernel messages)?
next prev parent reply other threads:[~2008-11-28 0:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-27 10:59 [PATCH] powerpc/pseries: Fix cpu hotplug Sebastien Dugue
2008-11-28 0:14 ` Nathan Lynch [this message]
2008-11-28 10:04 ` Sebastien Dugue
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=20081128001433.GI6830@localdomain \
--to=ntl@pobox.com \
--cc=Gilles.Carry@ext.bull.net \
--cc=jean-pierre.dion@bull.net \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=sebastien.dugue@bull.net \
--cc=will_schmidt@vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).