On Fri, May 09, 2014 at 09:10:50AM +0200, Ingo Molnar wrote:
>
> * Don Zickus wrote:
>
> > On Thu, May 08, 2014 at 07:35:01PM +0200, Ingo Molnar wrote:
> > >
> > > * Don Zickus wrote:
> > >
> > > > > > Again, I don't have a solution to juggle between PMI performance
> > > > > > and reliable
* Don Zickus wrote:
> On Thu, May 08, 2014 at 07:35:01PM +0200, Ingo Molnar wrote:
> >
> > * Don Zickus wrote:
> >
> > > > > Again, I don't have a solution to juggle between PMI performance
> > > > > and reliable delivery. We could do away with the spinlocks and
> > > > > go back to single
On Thu, May 08, 2014 at 07:35:01PM +0200, Ingo Molnar wrote:
>
> * Don Zickus wrote:
>
> > > > Again, I don't have a solution to juggle between PMI performance
> > > > and reliable delivery. We could do away with the spinlocks and
> > > > go back to single cpu delivery (like it used to be).
* Don Zickus wrote:
> > > Again, I don't have a solution to juggle between PMI performance
> > > and reliable delivery. We could do away with the spinlocks and
> > > go back to single cpu delivery (like it used to be). Then
> > > devise a mechanism to switch delivery to another cpu upon
>
On Wed, May 07, 2014 at 06:27:46PM +0200, Ingo Molnar wrote:
> > [...] But I guess in theory, if a PMI NMI comes in and before the
> > cpu can accept it and GHES NMI comes in, then it would suffice to
> > say it may get dropped. That would be not be good. Though the race
> > would be very sma
On Wed, May 07, 2014 at 06:27:46PM +0200, Ingo Molnar wrote:
>
> * Don Zickus wrote:
>
> > On Wed, May 07, 2014 at 05:38:54PM +0200, Ingo Molnar wrote:
> > >
> > > * Don Zickus wrote:
> > >
> > > > I noticed when debugging a perf problem on a machine with GHES enabled,
> > > > perf seemed slo
* Don Zickus wrote:
> On Wed, May 07, 2014 at 05:38:54PM +0200, Ingo Molnar wrote:
> >
> > * Don Zickus wrote:
> >
> > > I noticed when debugging a perf problem on a machine with GHES enabled,
> > > perf seemed slow. I then realized that the GHES NMI routine was taking
> > > a global lock al
On Wed, May 07, 2014 at 05:38:54PM +0200, Ingo Molnar wrote:
>
> * Don Zickus wrote:
>
> > I noticed when debugging a perf problem on a machine with GHES enabled,
> > perf seemed slow. I then realized that the GHES NMI routine was taking
> > a global lock all the time to inspect the hardware.
* Don Zickus wrote:
> I noticed when debugging a perf problem on a machine with GHES enabled,
> perf seemed slow. I then realized that the GHES NMI routine was taking
> a global lock all the time to inspect the hardware. This contended
> with all the local perf counters which did not need a lo
I noticed when debugging a perf problem on a machine with GHES enabled,
perf seemed slow. I then realized that the GHES NMI routine was taking
a global lock all the time to inspect the hardware. This contended
with all the local perf counters which did not need a lock. So each cpu
accidentally w
10 matches
Mail list logo