All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	tigran@aivazian.fsnet.co.uk, tglx@linutronix.de, mingo@elte.hu,
	hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	Linux PM mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [BUGFIX][PATCH] Freezer, CPU hotplug, x86 Microcode: Fix task freezing failures
Date: Mon, 03 Oct 2011 01:34:36 +0530	[thread overview]
Message-ID: <4E88C3D4.2020300@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111002195023.GC31799@mtj.dyndns.org>

Hi,

On 10/03/2011 01:20 AM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Oct 03, 2011 at 12:35:04AM +0530, Srivatsa S. Bhat wrote:
>> So, this patch addresses this issue by ensuring that microcode is not freed
>> from kernel memory, nor invalidated when a CPU goes offline. Thus once the
>> kernel gets the microcode during boot-up, it will never have to depend on
>> userspace ever again to get microcode, since it never releases the copy it
>> already has. So every run of the microcode callback for CPU online event will
>> now succeed irrespective of whether userspace is frozen or not. As a result,
>> this fixes the task freezing failure encountered while running CPU hotplug
>> stress test along with suspend/resume operations simultaneously.
> 
> I'm not familiar with how microcode is supposed to be managed but is
> it impossible for the newly hotplugged CPU (an actual hot unplug /
> plug) may not like the microcode loaded for the previous CPU?  Isn't
> that why CPU_DEAD was invalidating the microcode?
> 

Actually, looking at the code, I found that a copy of the microcode
is maintained by the kernel for every CPU. 
The relevant lines are:

arch/x86/include/asm/microcode.h:

struct ucode_cpu_info {
        struct cpu_signature    cpu_sig;
        int                     valid;
        void                    *mc;
};
extern struct ucode_cpu_info ucode_cpu_info[];


arch/x86/kernel/microcode_core.h:

struct ucode_cpu_info           ucode_cpu_info[NR_CPUS];


So when a CPU goes offline and comes back online, I don't see why the kernel
should not reuse the microcode that it already has. Anyhow the microcode will
not change. The same microcode would be requested from userspace again if the
kernel has freed its copy.

So what I feel is, earlier, the kernel used to invalidate the microcode for the CPU_DEAD
notification may be just to free the kernel's copy of the microcode as a memory
optimization (thinking that the microcode is not needed any more in kernel memory,
atleast for now).

This is my understanding. Please enlighten me if I am wrong.

-- 
Regards,
Srivatsa S. Bhat  <srivatsa.bhat@linux.vnet.ibm.com>
Linux Technology Center,
IBM India Systems and Technology Lab

  reply	other threads:[~2011-10-02 20:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-02 19:05 [BUGFIX][PATCH] Freezer, CPU hotplug, x86 Microcode: Fix task freezing failures Srivatsa S. Bhat
2011-10-02 19:36 ` Rafael J. Wysocki
2011-10-02 19:50 ` Tejun Heo
2011-10-02 20:04   ` Srivatsa S. Bhat [this message]
2011-10-03  0:40     ` Tejun Heo
2011-10-03  5:51       ` Srivatsa S. Bhat
2011-10-03  8:47         ` Borislav Petkov
2011-10-04  7:15           ` Tejun Heo
2011-10-04 13:15             ` Srivatsa S. Bhat
2011-10-04 13:46               ` Borislav Petkov
2011-10-04 17:14                 ` Borislav Petkov
2011-10-04 19:49                   ` Rafael J. Wysocki
2011-10-04 20:57                   ` Srivatsa S. Bhat
2011-10-05  7:21                     ` Borislav Petkov
2011-10-05  8:51                       ` Srivatsa S. Bhat
2011-10-05 20:26                         ` Rafael J. Wysocki
2011-10-05 21:15                           ` Srivatsa S. Bhat
2011-10-05 22:43                             ` Rafael J. Wysocki
2011-10-06  6:50                               ` Srivatsa S. Bhat
2011-10-06  8:34                                 ` Borislav Petkov
2011-10-06 15:47                                   ` Srivatsa S. Bhat
2011-10-06 18:11                                     ` Srivatsa S. Bhat
2011-10-06 20:35                                     ` [BUGFIX][PATCH RESEND] " Srivatsa S. Bhat
2011-10-06 22:13                                       ` Tejun Heo
2011-10-06 22:34                                         ` Borislav Petkov
2011-10-07 16:48                                           ` Srivatsa S. Bhat
2011-10-07 18:05                                             ` Borislav Petkov
2011-10-04 13:25             ` [BUGFIX][PATCH] " Borislav Petkov
2011-10-05  8:33         ` Srivatsa S. Bhat

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=4E88C3D4.2020300@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=tigran@aivazian.fsnet.co.uk \
    --cc=tj@kernel.org \
    --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.