Re: + perfmon2-reserve-system-calls.patch added to -mm tree

[Stephane Eranian]

Christoph,

On Tue, Nov 15, 2005 at 09:06:12AM +0000, Christoph Hellwig wrote:
> On Tue, Nov 15, 2005 at 12:50:26AM +0100, Arnd Bergmann wrote:
> > > --- 25/include/asm-powerpc/unistd.h~perfmon2-reserve-system-calls???????Mon Nov 14 15:27:32 2005
> > > +++ 25-akpm/include/asm-powerpc/unistd.h????????Mon Nov 14 15:27:32 2005
> > > @@ -296,8 +296,20 @@
> > > ?#define __NR_inotify_init??????275
> > > ?#define __NR_inotify_add_watch?276
> > > ?#define __NR_inotify_rm_watch??277
> > > +#define __NR_pfm_create_context????????278
> > > +#define __NR_pfm_write_pmcs????279
> > > +#define __NR_pfm_write_pmds????280
> > > +#define __NR_pfm_read_pmds?????281
> > > +#define __NR_pfm_load_context??282
> > > +#define __NR_pfm_start?????????283
> > > +#define __NR_pfm_stop??????????284
> > > +#define __NR_pfm_restart???????285
> > > +#define __NR_pfm_create_evtsets????????286
> > > +#define __NR_pfm_getinfo_evtsets 287
> > > +#define __NR_pfm_delete_evtsets 288
> > > +#define __NR_pfm_unload_context????????289
> > > ?
> > > -#define __NR_syscalls??????????278
> > > +#define __NR_syscalls??????????290
> 
> 
> anyway, this is an awfull lot of syscalls numbers for what essentially
> is a driver not core kernel functionality.  I think we should do an API
> review first.

I have cut the number of system calls as much as I could. Initially
this started out as a single multiplexing system call. Given the feedback
I received, I switched it over to multiple system calls. In retrospect,
I think this is better than the initial design.

As for your driver question, it is true that if we were only interested in
accessing the performance counters on a system-wide basis, like OProfile,
we could have implemented a device driver.

However we want both the ability to measure on a system-wide basis, i.e.,
across all kernel threads running on a processor, but also on a per kernel thread
basis. Both modes are important. Certain measurements do need to be applied
to a single thread, e.g., counting the number of retired instructions for /bin/ls.

The per-thread mode implies that, on context switch, the counters be saved
and restored like the rest of the machine state. I don't believe it is allowed
for a device driver to access to the context switch code.

Furthermore we want to have the monitoring interface be builtin to make it easier
for tools developers. A system call interface also gives us more flexibility
as to how the interface looks like, i.e., number and types of arguments.

Fro all those reasons, we felt that the syscall approach was the best.


> and why didn't this patch get sent to lkml for review?

For the last few months, I have been posting announces on lkml, perfctr-devel
and also linux-ia64-kernel about the new releases of the multi-platform perfmon
code base to sollicate feedback. I don't claim to know all the kernel internal
semantics and interfaces nor each hardware platofrm intricacies. Thus I welcome
any comments, complaints especially if they are constructive and poinpoint precise
problems in the code. This way I think we all make forward progress.

I will be releasing a new version of the patch this week. I would certainly welcome
your comments.

-- 
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/