From: Arnd Bergmann <arnd@arndb.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Stephane Eranian <eranian@googlemail.com>,
Eric Dumazet <dada1@cosmosbay.com>,
Robert Richter <robert.richter@amd.com>,
Arjan van de Ven <arjan@infradead.org>,
Peter Anvin <hpa@zytor.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [announce] Performance Counters for Linux, v6
Date: Sat, 21 Feb 2009 01:47:18 +0100 [thread overview]
Message-ID: <200902210147.20785.arnd@arndb.de> (raw)
In-Reply-To: <20090121185021.GA8852@elte.hu>
On Wednesday 21 January 2009, Ingo Molnar wrote:
> diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
> index 72353f6..4c8095f 100644
> --- a/arch/powerpc/include/asm/systbl.h
> +++ b/arch/powerpc/include/asm/systbl.h
> @@ -322,3 +322,4 @@ SYSCALL_SPU(epoll_create1)
> SYSCALL_SPU(dup3)
> SYSCALL_SPU(pipe2)
> SYSCALL(inotify_init1)
> +SYSCALL(perf_counter_open)
Is there a reason to forbid this on the SPU? It's probably not particularly
useful, but it shouldn't hurt.
> +
> +#ifdef CONFIG_PERF_COUNTERS
> +# include <asm/perf_counter.h>
> +#endif
> +
> +#include <linux/list.h>
> +#include <linux/mutex.h>
> +#include <linux/rculist.h>
> +#include <linux/rcupdate.h>
> +#include <linux/spinlock.h>
I guess all */perf_counter.h files should be exported, but then
the #ifdef won't work when the file is included from user space.
Also, some of the included headers are not exported.
> +/*
> + * Hardware event to monitor via a performance monitoring counter:
> + */
> +struct perf_counter_hw_event {
> + s64 type;
> +
> + u64 irq_period;
> + u32 record_type;
> +
> + u32 disabled : 1, /* off by default */
> + nmi : 1, /* NMI sampling */
> + raw : 1, /* raw event type */
> + inherit : 1, /* children inherit it */
> + pinned : 1, /* must always be on PMU */
> + exclusive : 1, /* only counter on PMU */
> +
> + __reserved_1 : 26;
> +
> + u64 __reserved_2;
> +};
When exported, the types should be __s64 etc instead of s64.
> +/*
> + * Ioctls that can be done on a perf counter fd:
> + */
> +#define PERF_COUNTER_IOC_ENABLE _IO('$', 0)
> +#define PERF_COUNTER_IOC_DISABLE _IO('$', 1)
> +
> +/*
> + * Kernel-internal data types:
> + */
The kernel internal parts of the header should be hidden in #ifdef
__KERNEL__.
> +
> +asmlinkage int sys_perf_counter_open(
> +
> + struct perf_counter_hw_event *hw_event_uptr __user,
> + pid_t pid,
> + int cpu,
> + int group_fd);
For the syscall, I'd suggest sys_perf_counter_fd or sys_perfcounterfd
to go along with signalfd, eventfd, etc. The only other _open syscall
we have is sys_mq_open(), which is different since it actually performs
an open() on a (hidden) file.
All system calls should return a 'long' value to make sure that the
errno handling works on all architectures.
> +static const struct file_operations perf_fops = {
> + .release = perf_release,
> + .read = perf_read,
> + .poll = perf_poll,
> + .unlocked_ioctl = perf_ioctl,
> + .compat_ioctl = perf_ioctl,
> +};
It feels inconsistent to combine a syscall for getting the fd with ioctl.
Assuming the interface is semantically right, I'd suggest using either
a chardev with more ioctls or more syscalls but not both:
asmlinkage long sys_perfcounter_fd(
struct perf_counter_hw_event *hw_event_uptr __user,
pid_t pid,
int cpu,
int group_fd);
asmlinkage long sys_perfcounter_setflags(int fd, u32 flags);
or
struct perf_counter_setup {
struct perf_counter_hw_event event;
__u64 pid;
__u32 cpu;
__u32 group_fd;
};
#define PERF_COUNTER_IOC_SETUP _IOW('$', 1, struct perf_counter_setup)
#define PERF_COUNTER_IOC_SETFLAGS _IOW('$', 2, __u32)
Arnd <><
next prev parent reply other threads:[~2009-02-21 0:48 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 18:50 [announce] Performance Counters for Linux, v6 Ingo Molnar
2009-01-21 19:34 ` Randy Dunlap
2009-01-21 19:56 ` Ingo Molnar
2009-01-21 21:14 ` Randy Dunlap
2009-01-22 11:22 ` Karel Zak
2009-01-22 12:04 ` Karel Zak
2009-01-22 12:06 ` Ingo Molnar
2009-01-26 1:06 ` Corey Ashford
2009-01-26 9:13 ` stephane eranian
2009-01-26 15:17 ` Ingo Molnar
2009-01-26 16:55 ` stephane eranian
2009-01-26 19:13 ` Corey Ashford
2009-01-26 19:39 ` [perfmon2] " Luck, Tony
2009-01-26 22:10 ` Ingo Molnar
2009-01-26 22:15 ` Ingo Molnar
2009-01-26 23:41 ` Corey Ashford
2009-01-29 2:10 ` Corey Ashford
2009-01-29 12:32 ` stephane eranian
2009-01-29 20:01 ` Corey Ashford
2009-01-29 21:44 ` stephane eranian
2009-02-19 21:53 ` Corey Ashford
2009-02-20 8:10 ` Ingo Molnar
2009-02-20 22:38 ` Corey Ashford
2009-02-20 22:47 ` Peter Zijlstra
2009-02-20 23:04 ` Corey Ashford
2009-02-20 23:24 ` stephane eranian
2009-02-20 23:58 ` Corey Ashford
2009-02-21 0:47 ` Arnd Bergmann [this message]
2009-02-26 9:49 ` Paul Mackerras
2009-02-26 13:37 ` Arnd Bergmann
2009-03-09 1:39 ` Robert Richter
2009-03-09 23:01 ` Paul Mackerras
2009-03-10 9:44 ` Robert Richter
2009-03-10 10:29 ` Peter Zijlstra
2009-03-10 11:49 ` Paul Mackerras
2009-03-10 11:53 ` Ingo Molnar
2009-03-10 16:26 ` Robert Richter
2009-03-10 17:27 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200902210147.20785.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=efault@gmx.de \
--cc=eranian@googlemail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox