Re: [Perfctr-devel] perfctr and Linus' tree?

Re: [Perfctr-devel] perfctr and Linus' tree?

[Mikael Pettersson]

On 07 Mar 2003 15:14:15 -0500, Albert Cahalan wrote:
>Mikael Pettersson writes:
>
>> I'm planning to simplify the kernel <--> user-space
>> interface in perfctr-2.6 (drop /proc/pid/perfctr and
>> go back to /dev/perfctr), and then I _think_ I can
>> do a version that doesn't require patching kernel
>> source. (It will do binary code patching at module
>> load-time instead. Horrible as that sounds, it's
>> easier to deal with for users.)
>
>That would make porting more difficult. I don't think
>these changes will help you gain acceptance.

I don't like patching kernel object code at all. But the #1
usability problem I'm facing is that to use the stuff, people
_must_ patch and rebuild their kernels, due to the callbacks
from switch_to and a few other places, and the task_struct
layout change. That scares away some people, and some try it
but get it wrong with confusing (and hard to debug) results.

(Besides, patching and recompiling the kernel doesn't always work.
There are examples of binary-only HW vendor modules that are
specific to certain versions of certain vendors' binary kernels.)

Naturally, the normal procedure of rebuilding the kernel from
patched sources would remain as the default. The object code
patching approach (which is what I'd use for a plug-and-play
binary .rpm for example) would basically use System.map and a
glue module to do the patching (installing callbacks), and then
the stock driver module would be inserted as usual.

With Linus ignoring the patch, the driver needing callbacks from
process scheduling/fork/exit/execve points, and users having
problems with kernel recompiles, what do you expect me to do?

/Mikael

Re: [Perfctr-devel] perfctr and Linus' tree?

[Hiro Yoshioka]

From: Mikael Pettersson <mikpe@user.it.uu.se>
> Hiro Yoshioka writes:
>  > I have a question. Is there any progress on merging the
>  > perfctr patch to Linus' kernel tree?
>  > 
>  > http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.0/0647.html
>  > 
>  > I found the DCL patch set includes the perfctr patch.
>  > http://lists.osdl.org/pipermail/dcl_developer/2003-March/000009.html
> 
> No progress since Linus totally ignored it, but at least two
> perfctr-patched trees exist. OSDL does one for the development
> kernel, and Jack Perdue has pre-patched RedHat kernel .rpms.
> (For Jack's stuff, check out PAPI -> Links -> Related Software.)
> 
> I'm planning to simplify the kernel <--> user-space interface in
> perfctr-2.6 (drop /proc/pid/perfctr and go back to /dev/perfctr),
> and then I _think_ I can do a version that doesn't require patching
> kernel source. (It will do binary code patching at module load-time
> instead. Horrible as that sounds, it's easier to deal with for users.)

I like /proc/pid/perfctr interface (virtual PMC mode).

The following patch should be included into the main line kernel,
shouldn't it?

--- linux-2.5.62-perfctr/include/asm-i386/processor.h.~1~       2003-02-18 02:06
:53.000000000 +0100
+++ linux-2.5.62-perfctr/include/asm-i386/processor.h   2003-02-18 02:18:36.0000
00000 +0100
@@ -372,6 +372,11 @@
        unsigned long __cacheline_filler[5];
 };
 
+/*
+ * Virtual per-process performance-monitoring counters.
+ */
+struct vperfctr;       /* opaque; no need to depend on <linux/perfctr.h> */
+
 struct thread_struct {
 /* cached TLS descriptors. */
        struct desc_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
@@ -393,6 +398,8 @@
        unsigned int            saved_fs, saved_gs;
 /* IO permissions */
        unsigned long   *ts_io_bitmap;
+/* performance counters */
+       struct vperfctr *perfctr;
 };
 
 #define INIT_THREAD  {                                                 \

---------------------------------------------

I think a per process (thread) performance monitoring is very
important.

Thanks in advance,
  Hiro

Re: [Perfctr-devel] perfctr and Linus' tree?

[Albert Cahalan]

Mikael Pettersson writes:

> I'm planning to simplify the kernel <--> user-space
> interface in perfctr-2.6 (drop /proc/pid/perfctr and
> go back to /dev/perfctr), and then I _think_ I can
> do a version that doesn't require patching kernel
> source. (It will do binary code patching at module
> load-time instead. Horrible as that sounds, it's
> easier to deal with for users.)

That would make porting more difficult. I don't think
these changes will help you gain acceptance.

Re: [Perfctr-devel] perfctr and Linus' tree?

[Mikael Pettersson]

Hiro Yoshioka writes:
 > I have a question. Is there any progress on merging the
 > perfctr patch to Linus' kernel tree?
 > 
 > http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.0/0647.html
 > 
 > I found the DCL patch set includes the perfctr patch.
 > http://lists.osdl.org/pipermail/dcl_developer/2003-March/000009.html

No progress since Linus totally ignored it, but at least two
perfctr-patched trees exist. OSDL does one for the development
kernel, and Jack Perdue has pre-patched RedHat kernel .rpms.
(For Jack's stuff, check out PAPI -> Links -> Related Software.)

I'm planning to simplify the kernel <--> user-space interface in
perfctr-2.6 (drop /proc/pid/perfctr and go back to /dev/perfctr),
and then I _think_ I can do a version that doesn't require patching
kernel source. (It will do binary code patching at module load-time
instead. Horrible as that sounds, it's easier to deal with for users.)

/Mikael