All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Christopher Covington
	<cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Richard Cochran
	<richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
	Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Paul Mackerras <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>,
	John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC 2/2] perf: Marker software event and ioctl
Date: Fri, 12 Sep 2014 10:49:10 -0300	[thread overview]
Message-ID: <20140912134910.GG1801@kernel.org> (raw)
In-Reply-To: <1410526672.16936.52.camel@hornet>

Em Fri, Sep 12, 2014 at 01:57:52PM +0100, Pawel Moll escreveu:
> On Fri, 2014-09-12 at 13:43 +0100, Christopher Covington wrote:
> > Just to ask the dumb questions in case the answers I've come up with are
> > wrong: What is PAGE_SIZE on an arm64 kernel? 
 
> It's either 4 or 64k, depending on CONFIG_ARM64_64K_PAGES.
 
> > How does userspace know?

> #include <unistd.h>
> #include <stdio.h>
 
> int main(void)
> {
> 	printf("%ld\n", sysconf(_SC_PAGESIZE));
> 	return 0;
> }
 
> Now a word of explanation. The PAGE_SIZE limitation was shamelessly
> stolen from perf_event_set_filter() (so PERF_EVENT_IOC_SET_FILTER) as an
> attempt to address a problem of passing a zero-terminated string from
> userspace. Simply speaking - there must be some limitation, and a page
> size seem as good as any other. I have strong doubts about this myself,
> so all alternative ideas are more than welcome.
 
> As I mentioned in the cover letter, maybe this simply shouldn't be a
> string? I made it like this to mimic trace_marker, but maybe an integer
> value + some kind of a dictionary in userspace is a better approach? I
> belive that ftrace's maker is taking a string, because it's: 1. natural
> for its interface and 2. anyone (sort of) can write to it, so it's hard
> to assume anything. In this case the user "owns" the perf data, so he
> could handle int<->whatever-else relation table...

Perhaps both? I.e. an u64 followed from a string, if the u64 is zero,
then there is a string right after it?

- Arnaldo

WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Christopher Covington <cov@codeaurora.org>,
	Richard Cochran <richardcochran@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Paul Mackerras <paulus@samba.org>,
	John Stultz <john.stultz@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [RFC 2/2] perf: Marker software event and ioctl
Date: Fri, 12 Sep 2014 10:49:10 -0300	[thread overview]
Message-ID: <20140912134910.GG1801@kernel.org> (raw)
In-Reply-To: <1410526672.16936.52.camel@hornet>

Em Fri, Sep 12, 2014 at 01:57:52PM +0100, Pawel Moll escreveu:
> On Fri, 2014-09-12 at 13:43 +0100, Christopher Covington wrote:
> > Just to ask the dumb questions in case the answers I've come up with are
> > wrong: What is PAGE_SIZE on an arm64 kernel? 
 
> It's either 4 or 64k, depending on CONFIG_ARM64_64K_PAGES.
 
> > How does userspace know?

> #include <unistd.h>
> #include <stdio.h>
 
> int main(void)
> {
> 	printf("%ld\n", sysconf(_SC_PAGESIZE));
> 	return 0;
> }
 
> Now a word of explanation. The PAGE_SIZE limitation was shamelessly
> stolen from perf_event_set_filter() (so PERF_EVENT_IOC_SET_FILTER) as an
> attempt to address a problem of passing a zero-terminated string from
> userspace. Simply speaking - there must be some limitation, and a page
> size seem as good as any other. I have strong doubts about this myself,
> so all alternative ideas are more than welcome.
 
> As I mentioned in the cover letter, maybe this simply shouldn't be a
> string? I made it like this to mimic trace_marker, but maybe an integer
> value + some kind of a dictionary in userspace is a better approach? I
> belive that ftrace's maker is taking a string, because it's: 1. natural
> for its interface and 2. anyone (sort of) can write to it, so it's hard
> to assume anything. In this case the user "owns" the perf data, so he
> could handle int<->whatever-else relation table...

Perhaps both? I.e. an u64 followed from a string, if the u64 is zero,
then there is a string right after it?

- Arnaldo

  reply	other threads:[~2014-09-12 13:49 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12 11:48 [RFC 0/2] Yet another take at user/kernel time correlation problem Pawel Moll
2014-09-12 11:48 ` [RFC 1/2] perf: Add sampling of the raw monotonic clock Pawel Moll
     [not found] ` <1410522513-1045-1-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2014-09-12 11:48   ` [RFC 2/2] perf: Marker software event and ioctl Pawel Moll
2014-09-12 11:48     ` Pawel Moll
     [not found]     ` <1410522513-1045-3-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2014-09-12 12:43       ` Christopher Covington
2014-09-12 12:43         ` Christopher Covington
     [not found]         ` <5412EA7A.9020807-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-09-12 12:57           ` Pawel Moll
2014-09-12 12:57             ` Pawel Moll
2014-09-12 13:49             ` Arnaldo Carvalho de Melo [this message]
2014-09-12 13:49               ` Arnaldo Carvalho de Melo
     [not found]               ` <20140912134910.GG1801-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-09-12 13:58                 ` Pawel Moll
2014-09-12 13:58                   ` Pawel Moll
2014-09-12 16:19                   ` Arnaldo Carvalho de Melo
2014-09-12 16:19                     ` Arnaldo Carvalho de Melo
     [not found]                     ` <20140912161934.GJ1801-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-09-15 17:27                       ` Pawel Moll
2014-09-15 17:27                         ` Pawel Moll
2014-09-15 18:31                         ` Arnaldo Carvalho de Melo
2014-09-15 18:31                           ` Arnaldo Carvalho de Melo
     [not found]                           ` <20140915183101.GE11199-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-09-16 16:33                             ` Pawel Moll
2014-09-16 16:33                               ` Pawel Moll
2014-09-12 14:00             ` Christopher Covington
2014-09-12 14:00               ` Christopher Covington
2014-09-12 17:37       ` David Ahern
2014-09-12 17:37         ` David Ahern
     [not found]         ` <54132F63.1010401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-09-12 20:44           ` Arnaldo Carvalho de Melo
2014-09-12 20:44             ` Arnaldo Carvalho de Melo
2014-09-14 15:43             ` David Ahern
     [not found]               ` <5415B790.5010607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-09-15 17:18                 ` Pawel Moll
2014-09-15 17:18                   ` Pawel Moll
2014-09-16  7:44                 ` Ingo Molnar
2014-09-16  7:44                   ` Ingo Molnar
     [not found]                   ` <20140916074421.GA21295-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-09-16 16:37                     ` Pawel Moll
2014-09-16 16:37                       ` Pawel Moll
2014-09-16 17:58                       ` Ingo Molnar
2014-09-16 17:58                         ` 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=20140912134910.GG1801@kernel.org \
    --to=acme-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
    --cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
    --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
    /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.