All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Brian Gerst <brgerst@gmail.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Asit K Mallick <asit.k.mallick@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Arjan van de Ven <arjan.van.de.ven@intel.com>,
	Suresh B Siddha <suresh.b.siddha@intel.com>,
	Len Brown <len.brown@intel.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Chen Gong <gong.chen@linux.intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-pm <linux-pm@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v5 10/12] x86/mtrr/main.c: Ask the first online CPU to save mtrr
Date: Sun, 15 Jan 2012 16:07:44 -0800	[thread overview]
Message-ID: <4F136A50.80203@zytor.com> (raw)
In-Reply-To: <CAMzpN2hfCCarbn+CDGrQuUaXYT29HpRd+9n0EKWvZdgLdqdAhA@mail.gmail.com>

On 01/12/2012 04:33 AM, Brian Gerst wrote:
> On Wed, Jan 11, 2012 at 12:04 PM, Fenghua Yu <fenghua.yu@intel.com> wrote:
>> From: Fenghua Yu <fenghua.yu@intel.com>
>>
>> Ask the first online CPU to save mtrr instead of asking BSP. BSP could be
>> offline when mtrr_save_state() is called.
> 
> If you can use any non-boot cpu to save the MTRRs why not just use the
> current cpu?  They should all be in sync anyways.
> 

A much bigger question: why do we ever bother saving the MTRR state per
se?  We examine the MTRR state -- we have to -- during boot, and it
should never diverge from the state set by the OS from that point on --
we'll need to set it back to that.  So we should just keep track of what
the correct MTRR state is at all times.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2012-01-16  0:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11 17:04 [PATCH v5 0/12] x86: Arbitrary CPU hot(un)plug support Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 01/12] Documentations/cpu-hotplug.tx, kernel-parameters.txt: Add x86 CPU0 online/offline feature Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 02/12] x86/Kconfig: Add config switch for CPU0 hotplug Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 03/12] x86/topology.c: Support functions for CPU0 online/offline Fenghua Yu
2012-01-16 17:35   ` Ben Hutchings
2012-01-24 22:31     ` Yu, Fenghua
2012-01-24 22:52       ` Ben Hutchings
2012-01-24 23:00         ` Yu, Fenghua
2012-01-11 17:04 ` [PATCH v5 04/12] x86/smpboot.c: Don't offline CPU0 if any irq can not be migrated out of it and remove CPU0 check in smp_callin() Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 05/12] x86/power/cpu.c: Don't hibernate/suspend if CPU0 is offline Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 06/12] x86/head_64.S: Define start_cpu0 Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 07/12] x86/head_32.S: " Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 08/12] x86/smpboot.c: Wake up CPU0 via NMI instead of INITs Fenghua Yu
2012-01-12 12:31   ` Brian Gerst
2012-01-11 17:04 ` [PATCH v5 09/12] x86/common.c: Init CPU0 data during CPU0 online Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 10/12] x86/mtrr/main.c: Ask the first online CPU to save mtrr Fenghua Yu
2012-01-12 12:33   ` Brian Gerst
2012-01-16  0:07     ` H. Peter Anvin [this message]
2012-01-25 17:58       ` Yu, Fenghua
2012-01-25 19:01       ` Yu, Fenghua
2012-01-11 17:04 ` [PATCH v5 11/12] x86/i387.c: Thread xstate is initialized only on CPU0 once Fenghua Yu
2012-01-11 17:04 ` [PATCH v5 12/12] x86/topology.c: debug CPU0 hotplug Fenghua Yu
2012-01-15 15:24   ` Jiang Liu

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=4F136A50.80203@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan.van.de.ven@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=brgerst@gmail.com \
    --cc=fenghua.yu@intel.com \
    --cc=gong.chen@linux.intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rdunlap@xenotime.net \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.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.