Messages in this thread Patch in this message | | | Date | Wed, 16 Nov 2005 02:24:31 -0800 | From | Stephane Eranian <> | Subject | Re: + perfmon2-reserve-system-calls.patch added to -mm tree |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |