On Tue, Jan 14, 2014 at 05:07:52PM +0100, Alexander Gordeev wrote:
> On Mon, Jan 13, 2014 at 04:50:37PM +0100, Frederic Weisbecker wrote:
> > On Sat, Jan 04, 2014 at 07:22:32PM +0100, Alexander Gordeev wrote:
> > > Hello,
> > >
> > > This is version 2 of RFC "perf: IRQ-bound performance events". T
On Mon, Jan 13, 2014 at 04:50:37PM +0100, Frederic Weisbecker wrote:
> On Sat, Jan 04, 2014 at 07:22:32PM +0100, Alexander Gordeev wrote:
> > Hello,
> >
> > This is version 2 of RFC "perf: IRQ-bound performance events". That is an
> > introduction of IRQ-bound performance events - ones that only c
On Sat, Jan 04, 2014 at 07:22:32PM +0100, Alexander Gordeev wrote:
> Hello,
>
> This is version 2 of RFC "perf: IRQ-bound performance events". That is an
> introduction of IRQ-bound performance events - ones that only count in a
> context of a hardware interrupt handler. Ingo suggested to extend t
On Sun, Jan 05, 2014 at 09:59:49AM -0800, Andi Kleen wrote:
> > This is version 2 of RFC "perf: IRQ-bound performance events". That is an
> > introduction of IRQ-bound performance events - ones that only count in a
> > context of a hardware interrupt handler. Ingo suggested to extend this
> > funct
On Sat, Jan 04, 2014 at 07:22:32PM +0100, Alexander Gordeev wrote:
> Hello,
>
> This is version 2 of RFC "perf: IRQ-bound performance events". That is an
> introduction of IRQ-bound performance events - ones that only count in a
> context of a hardware interrupt handler. Ingo suggested to extend t
Hello,
This is version 2 of RFC "perf: IRQ-bound performance events". That is an
introduction of IRQ-bound performance events - ones that only count in a
context of a hardware interrupt handler. Ingo suggested to extend this
functionality to softirq and threaded handlers as well:
[quote]
Looks u
6 matches
Mail list logo