All of lore.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 18:26:38 +0200	[thread overview]
Message-ID: <20090521162638.GA10824@aftab> (raw)
In-Reply-To: <4A156361.2040507@zytor.com>

On Thu, May 21, 2009 at 07:21:21AM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> >>>
> >> 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.
> > 
> 
> It *allows* concurrent execution.  It doesn't *guarantee* concurrent
> execution.

Exactly what I'm trying to say.

> > 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.
> 
> Only if we care about the additional performance of having it be
> nonserializing.

Well, let's do the nonserializing thing and have it done right from the
beginning. We might not care now but who knows..?

-- 
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 16:27 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
2009-05-21 14:21             ` H. Peter Anvin
2009-05-21 16:26               ` Borislav Petkov [this message]
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=20090521162638.GA10824@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 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.