All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm/perf: Fix pmu percpu irq handling at hotplug.
Date: Tue, 30 Aug 2016 18:32:25 +0100	[thread overview]
Message-ID: <20160830173224.GN1223@leverpostej> (raw)
In-Reply-To: <20160826094800.GD13554@arm.com>

Hi,

On Fri, Aug 26, 2016 at 10:48:00AM +0100, Will Deacon wrote:
> On Fri, Aug 19, 2016 at 03:25:14PM +0100, Mark Rutland wrote:
> > On Thu, Aug 18, 2016 at 01:24:38PM -0700, Yabin Cui wrote:
> > >    If the cpu pmu is using a percpu irq: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> > >    ? ? ??
> > >    1. When a cpu is down, we should disable pmu irq on ? ? ? ? ? ? ? ? ? ? ?
> > >    that cpu. Otherwise, if the cpu is still down when ? ? ? ? ? ? ? ? ? ? ? ?
> > >    the last perf event is released, the pmu irq can't ? ? ? ? ? ? ? ? ? ? ? ?
> > >    be freed. Because the irq is still enabled on the ? ? ? ? ? ? ? ? ? ? ? ?
> > >    offlined cpu. And following perf_event_open() ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> > >    syscalls will fail. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> > >
> > >    2. When a cpu is up, we should enable pmu irq on ? ? ? ? ? ? ? ? ? ? ? ? ?
> > >    that cpu. Otherwise, profiling tools can't sample ? ? ? ? ? ? ? ? ? ? ? ?
> > >    events on the cpu before all perf events are ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> > >    released, because pmu irq is disabled on that cpu. ? ? ? ? ? ? ? ? ? ? ? ?

[...]

> > Rather than adding more moving parts to the IRQ manipulation logic, I'd
> > rather we rework the IRQ manipulation logic to:
> > 
> > * At probe time, request all the interrupts. If we can't, bail out and
> >   fail the probe.
> > 
> > * Upon hotplug in (and at probe time), configure the affinity and
> >   enable the relevant interrupt(s).
> > 
> > * Upon hotplug out, disable the relevant interrupt.

> > I'm taking a look at doing the above, but I don't yet have a patch.
> 
> Any update on this? I'd quite like to do *something* to fix the issues
> reported here.

Apologies for the delay.

I've been away from my development hardware for the last week, so I
ahven't fought with this for a few days.

Given it's requiring that I practically rewrite of_pmu_irq_cfg and
friends, it may be better to take Yabin's patch for the timebeing if you
want a quick fix for this particular issue.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Yabin Cui <yabinc@google.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm/perf: Fix pmu percpu irq handling at hotplug.
Date: Tue, 30 Aug 2016 18:32:25 +0100	[thread overview]
Message-ID: <20160830173224.GN1223@leverpostej> (raw)
In-Reply-To: <20160826094800.GD13554@arm.com>

Hi,

On Fri, Aug 26, 2016 at 10:48:00AM +0100, Will Deacon wrote:
> On Fri, Aug 19, 2016 at 03:25:14PM +0100, Mark Rutland wrote:
> > On Thu, Aug 18, 2016 at 01:24:38PM -0700, Yabin Cui wrote:
> > >    If the cpu pmu is using a percpu irq:                                    
> > >          
> > >    1. When a cpu is down, we should disable pmu irq on                      
> > >    that cpu. Otherwise, if the cpu is still down when                        
> > >    the last perf event is released, the pmu irq can't                        
> > >    be freed. Because the irq is still enabled on the                        
> > >    offlined cpu. And following perf_event_open()                            
> > >    syscalls will fail.                                                      
> > >
> > >    2. When a cpu is up, we should enable pmu irq on                          
> > >    that cpu. Otherwise, profiling tools can't sample                        
> > >    events on the cpu before all perf events are                              
> > >    released, because pmu irq is disabled on that cpu.                        

[...]

> > Rather than adding more moving parts to the IRQ manipulation logic, I'd
> > rather we rework the IRQ manipulation logic to:
> > 
> > * At probe time, request all the interrupts. If we can't, bail out and
> >   fail the probe.
> > 
> > * Upon hotplug in (and at probe time), configure the affinity and
> >   enable the relevant interrupt(s).
> > 
> > * Upon hotplug out, disable the relevant interrupt.

> > I'm taking a look at doing the above, but I don't yet have a patch.
> 
> Any update on this? I'd quite like to do *something* to fix the issues
> reported here.

Apologies for the delay.

I've been away from my development hardware for the last week, so I
ahven't fought with this for a few days.

Given it's requiring that I practically rewrite of_pmu_irq_cfg and
friends, it may be better to take Yabin's patch for the timebeing if you
want a quick fix for this particular issue.

Thanks,
Mark.

  reply	other threads:[~2016-08-30 17:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CALJ9ZPMixfGKspzaz+vTGQZG4EaQB5Futss-aC-Z+8oztVX9Nw@mail.gmail.com>
2016-08-19 14:25 ` [PATCH] arm/perf: Fix pmu percpu irq handling at hotplug Mark Rutland
2016-08-19 14:25   ` Mark Rutland
2016-08-26  9:48   ` Will Deacon
2016-08-26  9:48     ` Will Deacon
2016-08-30 17:32     ` Mark Rutland [this message]
2016-08-30 17:32       ` Mark Rutland
2016-08-31 14:41       ` Will Deacon
2016-08-31 14:41         ` Will Deacon

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=20160830173224.GN1223@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.