public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 <><

  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