From: Toshi Kani <toshi.kani@hp.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, x86@kernel.org, bp@suse.de,
paul.gortmaker@windriver.com, JBeulich@suse.com,
prarit@redhat.com, drjones@redhat.com, riel@redhat.com,
gong.chen@linux.intel.com, andi@firstfloor.org, lenb@kernel.org,
rjw@rjwysocki.net, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v4 5/5] x86: initialize secondary CPU only if master CPU will wait for it
Date: Fri, 02 May 2014 08:52:22 -0600 [thread overview]
Message-ID: <1399042342.1789.87.camel@misato.fc.hp.com> (raw)
In-Reply-To: <20140502102120.5415bf5b@nial.usersys.redhat.com>
On Fri, 2014-05-02 at 10:21 +0200, Igor Mammedov wrote:
> On Thu, 01 May 2014 17:11:56 -0600
> Toshi Kani <toshi.kani@hp.com> wrote:
:
> > When 10s passed, the master could set a new flag, ex.
> > cpu_callout_error_mask, which wait_for_master_cpu() checks and call
> > play_dead() when it is set. This avoids AP to spin forever when 10s
> > becomes not long enough. But it does not have to be part of this
> > patchset, though.
> I'm reluctant to add another to already too many cpu_*_mask,
> maybe we could reuse cpu_initialized_mask by clearing it on timeout.
> This way AP spinning on cpu_callout_mask could notice it and halt itself.
I agree that there are too many cpu_* masks. IMHO, these cpu rendezvous
masks, initialized/callout/callin, should be combined into a per-cpu
flag. There is not much point of being individual masks.
Anyway, I do not think cpu_initialized_mask can be reused here.
> It would be better to make it separate patch on top of this series,
> to reduce delay of bugfixes in this series.
Agreed.
> >
> > > + if (!boot_error) {
> > > /*
> > > - * Wait 5s total for a response
> > > + * Wait till AP completes initial initialization
> >
> > We should generally avoid such wait w/o a timeout condition, but since
> > native_cpu_up() waits till cpu_online(cpu) anyway after this point, this
> If we don't wait here and fall through into tight loop waiting on
> cpu_online(cpu) in native_cpu_up() or check_tsc_sync_source() then
> stop_task for syncing MTTRs initiated from AP won't have a chance
> to run on the master CPU.
>
> > seems OK... I wonder if we need touch_nmi_watchdog(), though.
> There wasn't any touch_nmi_watchdog() in the original code and I don't
> think we need it here since we are not just spinning on CPU but giving
> control back to kernel calling schedule(), which would allow watchdog_task
> to do the job if needed.
Agreed.
Thanks,
-Toshi
next prev parent reply other threads:[~2014-05-02 15:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 15:11 [PATCH v4 0/5] x86: fix hang when AP bringup is too slow Igor Mammedov
2014-04-14 15:11 ` [PATCH v4 1/5] x86: fix list corruption on CPU hotplug Igor Mammedov
2014-04-30 21:18 ` Toshi Kani
2014-04-14 15:11 ` [PATCH v4 2/5] x86: fix memory corruption in acpi_unmap_lsapic() Igor Mammedov
2014-04-14 15:11 ` [PATCH v4 3/5] acpi_processor: do not mark present at boot but not onlined CPU as onlined Igor Mammedov
2014-04-15 5:48 ` Rafael J. Wysocki
2014-04-15 6:00 ` Igor Mammedov
2014-04-15 6:04 ` Ingo Molnar
2014-04-15 15:48 ` Rafael J. Wysocki
2014-04-15 5:53 ` Rafael J. Wysocki
2014-04-30 21:25 ` Toshi Kani
2014-05-02 11:32 ` Igor Mammedov
2014-05-02 17:23 ` Toshi Kani
2014-04-14 15:11 ` [PATCH v4 4/5] x86: log error on secondary CPU wakeup failure at ERR level Igor Mammedov
2014-04-30 21:30 ` Toshi Kani
2014-04-14 15:11 ` [PATCH v4 5/5] x86: initialize secondary CPU only if master CPU will wait for it Igor Mammedov
2014-05-01 23:11 ` Toshi Kani
2014-05-02 8:21 ` Igor Mammedov
2014-05-02 14:52 ` Toshi Kani [this message]
2014-05-05 20:26 ` Igor Mammedov
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=1399042342.1789.87.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=JBeulich@suse.com \
--cc=andi@firstfloor.org \
--cc=bp@suse.de \
--cc=drjones@redhat.com \
--cc=gong.chen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=imammedo@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=prarit@redhat.com \
--cc=riel@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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).