All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.