From: Peter Zijlstra <peterz@infradead.org>
To: Jason Vas Dias <jason.vas.dias@gmail.com>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>, andi <andi@firstfloor.org>
Subject: Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW
Date: Wed, 14 Mar 2018 14:11:20 +0100 [thread overview]
Message-ID: <20180314131120.GK4064@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CALyZvKzbLi6K9DFwOXu7h--MdxWFv9A3==0xORuQ=KwtJx3ZrQ@mail.gmail.com>
On Wed, Mar 14, 2018 at 12:55:20PM +0000, Jason Vas Dias wrote:
> > So you can avoid the whole ioctl(ENABLE), ioctl(DISABLE) nonsense and
> > just let them run and do:
> >
> > read(group_fd, &buf_pre, size);
> > /* your code section */
> > read(group_fd, &buf_post, size);
> >
> > /* compute buf_post - buf_pre */
> >
> > Which is only 2 system calls, not 4.
>
> But I can't, really - I am trying to restrict the
> performance counter measurements
> to only a subset of the code, and exclude
> performance measurement result processing -
> so the timeline is like:
> struct timespec t_start, t_end;
> perf_event_open(...);
> thread_main_loop() { ... do {
> t _ clock_gettime(CLOCK_MONOTONIC_RAW, &t_start);
> t+x _ enable_perf ();
> total_work = do_some_work();
> disable_perf ();
> clock_gettime(CLOCK_MONOTONIC_RAW, &t_end);
> t+y_
> read_perf_counters_and_store_results
> ( perf_grp_fd, &results , total_work,
> TS2T( &t_end ) - TS2T( &t_start)
> );
> } while (.... );
> }
>
> Now. here the bandwidth / performance results recorded by
> my 'read_perf_counters_and_store_results' method
> is very sensitive to the measurement of the OUTER
> elapsed time .
I still don't see why you have to do that enable_perf() / disable_perf()
stuff. What goes wrong if you just let them run and do 2
read_perf*() things?
next prev parent reply other threads:[~2018-03-14 13:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 7:01 Jason Vas Dias
2018-03-12 8:27 ` Peter Zijlstra
2018-03-13 23:45 ` Jason Vas Dias
2018-03-14 9:45 ` Peter Zijlstra
2018-03-14 12:55 ` Jason Vas Dias
2018-03-14 13:11 ` Peter Zijlstra [this message]
2018-03-14 13:12 ` Peter Zijlstra
2018-03-14 13:16 ` Peter Zijlstra
2018-03-14 13:29 ` Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2018-03-12 9:14 Jason Vas Dias
2018-03-12 17:41 ` kbuild test robot
2018-03-12 5:44 Jason Vas Dias
2018-03-12 5:33 Jason Vas Dias
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=20180314131120.GK4064@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andi@firstfloor.org \
--cc=jason.vas.dias@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome