public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <borislav.petkov@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: akpm@linux-foundation.org, greg@kroah.com, mingo@elte.hu,
	norsk5@yahoo.com, tglx@linutronix.de, mchehab@redhat.com,
	aris@redhat.com, edt@aei.ca, linux-kernel@vger.kernel.org,
	Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [PATCH 01/22] x86: add methods for writing of an MSR on several CPUs
Date: Thu, 21 May 2009 16:08:00 +0200	[thread overview]
Message-ID: <20090521140800.GA3462@aftab> (raw)
In-Reply-To: <4A147891.5000906@zytor.com>

On Wed, May 20, 2009 at 02:39:29PM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> > 
> > We currently need them for enabling the NB error reporting bank over
> > MCG_CTL on each core on the node. The question is whether we really need
> > the concurrency when accessing an MSR on several cores. With MCG_CTL,
> > BKDG says "It is expected that this register is programmed to the same
> > value in all nodes," but nothing concerning concurrency.
> > 
> > But you're right, if this interface is supposed to be generic enough,
> > it is probably wise to access an MSR concurrently. I could imagine
> > an obscure case where this is required. However, is sending IPIs
> > (smp_call_function_many) guaranteeing the needed concurrency? Or, should
> > it be more like how the mtrr code jumps through hoops (set_mtrr())
> > in order to ensure that _ALL_ registers have been written _before_
> > continuing?
> > 
> 
> smp_call_function_many() does allow concurrent execution.

Well, IMHO, not an absolutely concurrent execution since you can't
control at what moment in time the IPIs will be executed on each core,
IOW, the respective call function IPIs will generally not coincide on
each core at a given moment in time. This is especially true if you're
sending IPIs to cores across nodes.

And there's hypothetically a small window where you might get an
inconsistent MSR content across cores. It's a whole another question
whether this is going to be relevant.

> Looping over a list with smp_call_function_one() -- which you
> currently have -- is serializing, at which point we might just push
> the loop into the caller rather than worrying about a new interface.

So, the actual question is do we need that done in msr.c? If there are
no potential users, I could easily do the whole thing in the driver and
do not touch x86 code.

Hmm?

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632


  reply	other threads:[~2009-05-21 14:08 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-15 12:22 [RFC PATCH 00/21 v4] amd64_edac: EDAC module for AMD64 Borislav Petkov
2009-05-15 12:22 ` [PATCH 01/22] x86: add methods for writing of an MSR on several CPUs Borislav Petkov
2009-05-19 17:24   ` Borislav Petkov
2009-05-20  5:18     ` H. Peter Anvin
2009-05-20 14:49       ` Borislav Petkov
2009-05-20 21:39         ` H. Peter Anvin
2009-05-21 14:08           ` Borislav Petkov [this message]
2009-05-21 14:21             ` H. Peter Anvin
2009-05-21 16:26               ` Borislav Petkov
2009-05-21 17:38                 ` H. Peter Anvin
2009-05-22 14:39                   ` Borislav Petkov
2009-05-22 16:47                     ` H. Peter Anvin
2009-05-25 11:01                       ` Borislav Petkov
2009-05-25 11:02                         ` Borislav Petkov
2009-05-25 11:03                         ` Borislav Petkov
2009-05-15 12:22 ` [PATCH 02/22] edac: fold __func__ into edac_debug_printk Borislav Petkov
2009-05-15 13:25   ` Mauro Carvalho Chehab
2009-05-15 12:22 ` [PATCH 03/22] amd64_edac: add driver header Borislav Petkov
2009-05-15 12:22 ` [PATCH 04/22] amd64_edac: add debugging/testing code Borislav Petkov
2009-05-15 12:22 ` [PATCH 05/22] amd64_edac: add DRAM error injection logic using sysfs Borislav Petkov
2009-05-15 12:22 ` [PATCH 06/22] amd64_edac: add MCA error types Borislav Petkov
2009-05-15 12:22 ` [PATCH 07/22] amd64_edac: add memory scrubber interface Borislav Petkov
2009-05-15 12:22 ` [PATCH 08/22] amd64_edac: add sys addr to memory controller mapping helpers Borislav Petkov
2009-05-15 12:22 ` [PATCH 09/22] amd64_edac: add functionality to compute the DRAM hole Borislav Petkov
2009-05-15 12:22 ` [PATCH 10/22] amd64_edac: add DRAM address type conversion facilities Borislav Petkov
2009-05-15 12:22 ` [PATCH 11/22] amd64_edac: add helper to dump relevant registers Borislav Petkov
2009-05-15 12:22 ` [PATCH 12/22] amd64_edac: assign DRAM chip select base and mask in a family-specific way Borislav Petkov
2009-05-15 12:22 ` [PATCH 13/22] amd64_edac: add k8-specific methods Borislav Petkov
2009-05-15 12:22 ` [PATCH 14/22] amd64_edac: add F10h-and-later methods-p1 Borislav Petkov
2009-05-15 12:22 ` [PATCH 15/22] amd64_edac: add F10h-and-later methods-p2 Borislav Petkov
2009-05-15 12:22 ` [PATCH 16/22] amd64_edac: add F10h-and-later methods-p3 Borislav Petkov
2009-05-15 12:22 ` [PATCH 17/22] amd64_edac: add per-family descriptors Borislav Petkov
2009-05-15 12:22 ` [PATCH 18/22] amd64_edac: add ECC chipkill syndrome mapping table Borislav Petkov
2009-05-15 12:22 ` [PATCH 19/22] amd64_edac: add error decoding logic Borislav Petkov
2009-05-15 12:22 ` [PATCH 20/22] amd64_edac: add EDAC core-related initializers Borislav Petkov
2009-05-15 12:22 ` [PATCH 21/22] amd64_edac: add ECC reporting initializers Borislav Petkov
2009-05-15 12:22 ` [PATCH 22/22] amd64_edac: add module registration routines Borislav Petkov

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=20090521140800.GA3462@aftab \
    --to=borislav.petkov@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreas.herrmann3@amd.com \
    --cc=aris@redhat.com \
    --cc=edt@aei.ca \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=mingo@elte.hu \
    --cc=norsk5@yahoo.com \
    --cc=tglx@linutronix.de \
    /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