Support for alternative kernel profiler in a module

To allow an alternative kernel profiler using the ia64 perfomance counters to be loaded as a module, a couple of small changes are needed.

1) Define a new 'irqflags' bit (SA_PERCPU_IRQ) to allow a module to request a per-cpu irq.

2) Export init_tasks[] so that the module can adjust the state of psr.pp in the idle tasks for all CPUs.

I've attached the patch rather than inlining it in the hope that outlook won't sabotage it by folding long lines or playing with tabs and spaces.

-Tony Luck

It turns out that we don't really need to have init_tasks[] exported.

Here is a revised version of the patch with just the change to add SA_PERCPU_IRQ to the flags accepted by request_irq()

-Tony

-----Original Message-----
From: Luck, Tony [mailto:[email protected]]
Sent: Friday, January 04, 2002 5:04 PM
To: '[email protected]'
Cc: [email protected]
Subject: [Linux-ia64] [PATCH] Support for alternative kernel profiler in a module

To allow an alternative kernel profiler using the ia64 perfomance counters to be loaded as a module, a couple of small changes are needed.

1) Define a new 'irqflags' bit (SA_PERCPU_IRQ) to allow a module to request a per-cpu irq.

2) Export init_tasks[] so that the module can adjust the state of psr.pp in the idle tasks for all CPUs.

I've attached the patch rather than inlining it in the hope that outlook won't sabotage it by folding long lines or playing with tabs and spaces.

-Tony Luck

Tony> It turns out that we don't really need to have init_tasks[] Tony> exported. Here is a revised version of the patch with just Tony> the change to add SA_PERCPU_IRQ to the flags accepted by Tony> request_irq()

I'd like Stephane to take a look at this patch and see whether there are any potential bad interactions with the PMU code he is working on (due to the manipulation of the psr.pp bit). Other than that, the patch looks good to me.

	--david

Umh, my previous mail probably wasn't very clear: I did apply the patch to add the SA_PERCPU_IRQ.

	--david

We don't currently have any way for different software packages to share the performance counters, so it's very likely that there would be interactions with Stephane's PMU code (e.g. I rewrite cr.pmv to a new vector and re-write all of the pmc[] and pmd[] registers for my own purposes ... this will upset Stephane's code, similarly my code does not expect anyone else to touch any PMU registers, or fiddle with psr.pp/dcr.pp).

It would probably be safest to turn off CONFIG_PERFMON in a kernel that is going to load an alternate profiler ... my profiler seems to cope ok provided nobody calls sys_perfmonctl().

-Tony

Tony> We don't currently have any way for different software Tony> packages to share the performance counters, so it's very Tony> likely that there would be interactions with Stephane's PMU Tony> code (e.g. I rewrite cr.pmv to a new vector and re-write all Tony> of the pmc[] and pmd[] registers for my own purposes ... this Tony> will upset Stephane's code, similarly my code does not expect Tony> anyone else to touch any PMU registers, or fiddle with Tony> psr.pp/dcr.pp).

Tony> It would probably be safest to turn off CONFIG_PERFMON in a Tony> kernel that is going to load an alternate profiler ... my Tony> profiler seems to cope ok provided nobody calls Tony> sys_perfmonctl().

This hardly seems like an ideal solution. If you just want to keep your patch for yourself, that's probably OK, but if it is to become part of the kernel, we should look into a way for safely sharing the PMU. The first obvious way to try is to do the profiling you want on top of perfmon.

	--david