On Tue, Apr 28, 2015 at 02:44:28PM -0400, Don Zickus wrote:
> RAS doesn't go through the legacy ports (ie get_nmi_reason()). Instead it
> triggers the external NMI through a different bit (ioapic I think).
Well, I see it getting registered with __register_nmi_handler() which
adds it to the
On Tue, Apr 28, 2015 at 02:44:28PM -0400, Don Zickus wrote:
RAS doesn't go through the legacy ports (ie get_nmi_reason()). Instead it
triggers the external NMI through a different bit (ioapic I think).
Well, I see it getting registered with __register_nmi_handler() which
adds it to the
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, April 30, 2015 4:49 PM
>
> On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote:
> > Are there any such data around the SC and LL (MIPS)?
>
> What, you can't search the internet yourself?
I mean if LL can do what you
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Thursday, April 30, 2015 4:49 PM
On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote:
Are there any such data around the SC and LL (MIPS)?
What, you can't search the internet yourself?
I mean if LL can do what you exactly
On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote:
> Are there any such data around the SC and LL (MIPS)?
What, you can't search the internet yourself?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, April 29, 2015 4:14 PM
> Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote:
> > > > We absolutely want to use ato
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Wednesday, April 29, 2015 4:14 PM
Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote:
We absolutely want to use atomic_add_unless() because we get
On Thu, Apr 30, 2015 at 08:05:12AM +, Zheng, Lv wrote:
Are there any such data around the SC and LL (MIPS)?
What, you can't search the internet yourself?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line
On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote:
> > > We absolutely want to use atomic_add_unless() because we get to save us
> > > the expensive
> > >
> > > LOCK; CMPXCHG
> > >
> > > if the value was already 1. Which is exactly what this patch is trying
> > > to avoid - a thundering
On Wed, Apr 29, 2015 at 12:49:59AM +, Zheng, Lv wrote:
We absolutely want to use atomic_add_unless() because we get to save us
the expensive
LOCK; CMPXCHG
if the value was already 1. Which is exactly what this patch is trying
to avoid - a thundering herd of cores
Hi,
> From: Zheng, Lv
> Sent: Wednesday, April 29, 2015 8:25 AM
> Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Sent: Tuesday, April 28, 2015 9:59 PM
> > Subject
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, April 28, 2015 9:59 PM
> Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote:
> > > - raw_spin_lock(_nmi_lock);
> &
On Tue, Apr 28, 2015 at 06:22:29PM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2015 at 11:35:21AM -0400, Don Zickus wrote:
> > Your solution seems much simpler. :-)
>
> ... and I love simpler :-)
>
> > I followed up in another email stating I mis-spoke. I forgot this still
> > uses the
On Tue, Apr 28, 2015 at 11:35:21AM -0400, Don Zickus wrote:
> Your solution seems much simpler. :-)
... and I love simpler :-)
> I followed up in another email stating I mis-spoke. I forgot this still
> uses the NMI_LOCAL shared NMI. So every perf NMI, will also call the GHES
> handler to make
On Tue, Apr 28, 2015 at 04:55:48PM +0200, Borislav Petkov wrote:
> On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
> > On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> > > On Fri, 27 Mar 2015, Borislav Petkov wrote:
> > >
> > > > From: Jiri Kosina
> > > >
> > > > Since
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
> On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> > On Fri, 27 Mar 2015, Borislav Petkov wrote:
> >
> > > From: Jiri Kosina
> > >
> > > Since GHES sources are global, we theoretically need only a single CPU
> > > reading
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
> On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> > On Fri, 27 Mar 2015, Borislav Petkov wrote:
> >
> > > From: Jiri Kosina
> > >
> > > Since GHES sources are global, we theoretically need only a single CPU
> > > reading
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> On Fri, 27 Mar 2015, Borislav Petkov wrote:
>
> > From: Jiri Kosina
> >
> > Since GHES sources are global, we theoretically need only a single CPU
> > reading them per NMI instead of a thundering herd of CPUs waiting on a
> >
On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote:
> > - raw_spin_lock(_nmi_lock);
> > + if (!atomic_add_unless(_in_nmi, 1, 1))
> > + return ret;
> > +
>
> if (atomic_cmpxchg(_in_nmi, 0, 1))
> return ret;
Ok, now I understand what you mean.
We absolutely want to use
Hi,
I was talking about this patch.
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, March 27, 2015 5:23 PM
> Subject: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
>
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically need only a single CPU
>
On Tue, Apr 28, 2015 at 02:24:16AM +, Zheng, Lv wrote:
> > > #APP
> > > # 177 "./arch/x86/include/asm/atomic.h" 1
> > > .pushsection .smp_locks,"a"
> > > .balign 4
> > > .long 671f - .
> > > .popsection
> > > 671:
> > > lock; cmpxchgl %edx,ghes_in_nmi(%rip) # D.37056, MEM[(volatile u32
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
On Fri, 27 Mar 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading
On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote:
- raw_spin_lock(ghes_nmi_lock);
+ if (!atomic_add_unless(ghes_in_nmi, 1, 1))
+ return ret;
+
if (atomic_cmpxchg(ghes_in_nmi, 0, 1))
return ret;
Ok, now I understand what you mean.
We absolutely want to use
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
On Fri, 27 Mar 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Tuesday, April 28, 2015 9:59 PM
Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
On Tue, Apr 28, 2015 at 01:38:41PM +, Zheng, Lv wrote:
- raw_spin_lock(ghes_nmi_lock);
+ if (!atomic_add_unless
Hi,
From: Zheng, Lv
Sent: Wednesday, April 29, 2015 8:25 AM
Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Tuesday, April 28, 2015 9:59 PM
Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have
Hi,
I was talking about this patch.
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Friday, March 27, 2015 5:23 PM
Subject: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
On Fri, 27 Mar 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading
On Tue, Apr 28, 2015 at 04:55:48PM +0200, Borislav Petkov wrote:
On Tue, Apr 28, 2015 at 10:30:09AM -0400, Don Zickus wrote:
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
On Fri, 27 Mar 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES
On Tue, Apr 28, 2015 at 11:35:21AM -0400, Don Zickus wrote:
Your solution seems much simpler. :-)
... and I love simpler :-)
I followed up in another email stating I mis-spoke. I forgot this still
uses the NMI_LOCAL shared NMI. So every perf NMI, will also call the GHES
handler to make
On Tue, Apr 28, 2015 at 02:24:16AM +, Zheng, Lv wrote:
#APP
# 177 ./arch/x86/include/asm/atomic.h 1
.pushsection .smp_locks,a
.balign 4
.long 671f - .
.popsection
671:
lock; cmpxchgl %edx,ghes_in_nmi(%rip) # D.37056, MEM[(volatile u32
*)ghes_in_nmi]
# 0 2
On Tue, Apr 28, 2015 at 06:22:29PM +0200, Borislav Petkov wrote:
On Tue, Apr 28, 2015 at 11:35:21AM -0400, Don Zickus wrote:
Your solution seems much simpler. :-)
... and I love simpler :-)
I followed up in another email stating I mis-spoke. I forgot this still
uses the NMI_LOCAL
Hi,
> From: Zheng, Lv
> Sent: Tuesday, April 28, 2015 8:44 AM
>
> Hi,
>
> > From: Borislav Petkov [mailto:b...@alien8.de]
> > Sent: Monday, April 27, 2015 4:47 PM
> >
> > On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > > > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, April 27, 2015 4:47 PM
>
> On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> > > pt_regs *regs)
> > > struct ghes *ghes;
> > > int
On Thu, Apr 23, 2015 at 06:00:15PM +, Luck, Tony wrote:
> > I think we should apply this.
> >
> > Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific
> > accesses
>
> This looks to be true.
>
> > Tony, objections?
>
> No objections.
Thanks, queued for 4.2, pending one
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
> > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> > pt_regs *regs)
> > struct ghes *ghes;
> > int sev, ret = NMI_DONE;
> >
> > - raw_spin_lock(_nmi_lock);
> > + if (!atomic_add_unless(_in_nmi, 1,
On Thu, Apr 23, 2015 at 06:00:15PM +, Luck, Tony wrote:
I think we should apply this.
Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific
accesses
This looks to be true.
Tony, objections?
No objections.
Thanks, queued for 4.2, pending one last test I'm
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
@@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
pt_regs *regs)
struct ghes *ghes;
int sev, ret = NMI_DONE;
- raw_spin_lock(ghes_nmi_lock);
+ if (!atomic_add_unless(ghes_in_nmi, 1, 1))
+
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, April 27, 2015 4:47 PM
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
@@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
pt_regs *regs)
struct ghes *ghes;
int sev, ret =
Hi,
From: Zheng, Lv
Sent: Tuesday, April 28, 2015 8:44 AM
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, April 27, 2015 4:47 PM
On Mon, Apr 27, 2015 at 03:16:00AM +, Zheng, Lv wrote:
@@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, March 27, 2015 5:23 PM
>
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically need only a single CPU
> reading them per NMI instead of a thundering herd of CPUs waiting on a
> spinlock in NMI context for no
Hi,
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Friday, March 27, 2015 5:23 PM
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context
> I think we should apply this.
>
> Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific
> accesses
This looks to be true.
> Tony, objections?
No objections.
-Tony
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z�
On Thu, Apr 23, 2015 at 10:39:58AM +0200, Jiri Kosina wrote:
> Three weeks have passed, therefore I find this an appropriate time for a
> friendly ping :)
>
> Rafael? Naoya? Huang?
>
> This fixes a contention spinlock problem in NMI observed on a real HW, so
> it would be really nice to have
On Wed, 1 Apr 2015, Borislav Petkov wrote:
> > > From: Jiri Kosina
> > >
> > > Since GHES sources are global, we theoretically need only a single CPU
> > > reading them per NMI instead of a thundering herd of CPUs waiting on a
> > > spinlock in NMI context for no reason at all.
> >
> > I
I think we should apply this.
Here's why: nothing in the ghes_notify_nmi() handler does CPU-specific
accesses
This looks to be true.
Tony, objections?
No objections.
-Tony
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z�
On Thu, Apr 23, 2015 at 10:39:58AM +0200, Jiri Kosina wrote:
Three weeks have passed, therefore I find this an appropriate time for a
friendly ping :)
Rafael? Naoya? Huang?
This fixes a contention spinlock problem in NMI observed on a real HW, so
it would be really nice to have it
On Wed, 1 Apr 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context for no reason at all.
I
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
> On Fri, 27 Mar 2015, Borislav Petkov wrote:
>
> > From: Jiri Kosina
> >
> > Since GHES sources are global, we theoretically need only a single CPU
> > reading them per NMI instead of a thundering herd of CPUs waiting on a
> >
On Fri, 27 Mar 2015, Borislav Petkov wrote:
> From: Jiri Kosina
>
> Since GHES sources are global, we theoretically need only a single CPU
> reading them per NMI instead of a thundering herd of CPUs waiting on a
> spinlock in NMI context for no reason at all.
I originally wasn't 100% sure
On Fri, 27 Mar 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context for no reason at all.
I originally wasn't 100%
On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote:
On Fri, 27 Mar 2015, Borislav Petkov wrote:
From: Jiri Kosina jkos...@suse.cz
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
52 matches
Mail list logo
