All of lore.kernel.org
 help / color / mirror / Atom feed
From: "shenkai (D)" <shenkai8@huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>, Andy Lutomirski <luto@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	<hewenliang4@huawei.com>, <hushiyuan@huawei.com>,
	<luolongjun@huawei.com>, <hejingxian@huawei.com>
Subject: Re: [PATCH] use x86 cpu park to speedup smp_init in kexec situation
Date: Wed, 16 Dec 2020 22:18:31 +0800	[thread overview]
Message-ID: <06977da1-d148-0079-0e85-32d657d1a1de@huawei.com> (raw)
In-Reply-To: <87v9d2rrdq.fsf@nanos.tec.linutronix.de>

在 2020/12/16 18:12, Thomas Gleixner 写道:
> Kai,
>
> On Wed, Dec 16 2020 at 16:45, shenkai wrote:
>> 在 2020/12/16 5:20, Thomas Gleixner 写道:
>>>
>> Thanks for your and Andy's precious comments. I would like to take a try on
>>
>> reconstructing this patch to make it more decent and generic.
>>> It would be interesting to see the numbers just with play_dead() using
>>> hlt() or mwait(eax=0, 0) for the kexec case and no other change at all.
> Can you please as a first step look into this and check if the time
> changes?
>
> Thanks,
>
>          tglx
> .

After some tests, the conclusion that time cost is from deep C-state 
turns out to be wrong

Sorry for that.

Here is what I do:

In kexec case, first let APs spinwait like what I did  in that patch, 
but wake APs up by

sending apic INIT and SIPI  interrupts as normal procedure instead of 
writing to some

address and there is no acceleration (time cost is still 210ms).

So can we say that the main time cost is from apic INIT and SIPI 
interrupts and the handling

of them instead of deep C-state?


I didn't test with play_dead() because in kexec case, one new kernel 
will be started and APs can't be

waken up by normal interrupts like in hibernate case for the irq vectors 
are gone with the old kernel.

Or maybe I didn't get the point correctly?


Best regards

Kai




  reply	other threads:[~2020-12-16 14:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15 14:46 [PATCH] use x86 cpu park to speedup smp_init in kexec situation shenkai (D)
2020-12-15 16:31 ` Andy Lutomirski
2020-12-15 21:20   ` Thomas Gleixner
2020-12-16  8:45     ` shenkai (D)
2020-12-16 10:12       ` Thomas Gleixner
2020-12-16 14:18         ` shenkai (D) [this message]
2020-12-16 15:31           ` Thomas Gleixner
2020-12-17 14:53             ` shenkai (D)
2021-01-07 15:18             ` David Woodhouse
2021-01-19 12:12     ` David Woodhouse
2021-01-21 14:55       ` Thomas Gleixner
2021-01-21 15:42         ` David Woodhouse
2021-01-21 17:34           ` David Woodhouse
2021-01-21 19:59         ` [PATCH] x86/apic/x2apic: Fix parallel handling of cluster_mask David Woodhouse
2021-02-01 10:36         ` [PATCH] use x86 cpu park to speedup smp_init in kexec situation David Woodhouse
2021-02-01 10:38           ` [PATCH 1/6] x86/apic/x2apic: Fix parallel handling of cluster_mask David Woodhouse
2021-02-01 10:38             ` [PATCH 2/6] cpu/hotplug: Add dynamic states before CPUHP_BRINGUP_CPU for parallel bringup David Woodhouse
2021-02-01 10:38             ` [PATCH 3/6] x86/smpboot: Reference count on smpboot_setup_warm_reset_vector() David Woodhouse
2021-02-01 10:38             ` [PATCH 4/6] x86/smpboot: Split up native_cpu_up into separate phases David Woodhouse
2021-02-01 10:38             ` [PATCH 5/6] cpu/hotplug: Move idle_thread_get() to <linux/smpboot.h> David Woodhouse
2021-02-01 10:38             ` [PATCH 6/6] pre states for x86 David Woodhouse
     [not found] <87ft22dxop.fsf@nanos.tec.linutronix.de>
     [not found] ` <27357c74bdc3b52bdf59e6f48cd8690495116d64.camel@infradead.org>
     [not found]   ` <877dnedt7l.fsf@nanos.tec.linutronix.de>
     [not found]     ` <87zh09tcqz.fsf@nanos.tec.linutronix.de>
2021-02-16 13:53       ` [PATCH] use x86 cpu park to speedup smp_init in kexec situation David Woodhouse
2021-02-16 15:10         ` David Woodhouse
2021-02-16 21:18           ` David Woodhouse
2021-12-08 14:14           ` David Woodhouse
2021-12-08 14:50             ` Paul E. McKenney
2021-12-08 15:10               ` David Woodhouse
2021-12-08 16:57                 ` David Woodhouse
2021-12-08 17:35                   ` Paul E. McKenney
2021-12-08 18:32                     ` David Woodhouse
2021-12-08 19:03                       ` Paul E. McKenney
2021-12-08 20:35                         ` David Woodhouse
2021-12-08 21:09                           ` Paul E. McKenney

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=06977da1-d148-0079-0e85-32d657d1a1de@huawei.com \
    --to=shenkai8@huawei.com \
    --cc=bp@alien8.de \
    --cc=hejingxian@huawei.com \
    --cc=hewenliang4@huawei.com \
    --cc=hpa@zytor.com \
    --cc=hushiyuan@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luolongjun@huawei.com \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --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 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.