All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@google.com>
To: linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, mingo@elte.hu, paulus@samba.org,
	davem@davemloft.net, fweisbec@gmail.com,
	perfmon2-devel@lists.sf.net, eranian@gmail.com,
	eranian@google.com, robert.richter@amd.com
Subject: [PATCH 0/2] perf_events: fix the fix for transaction recovery in group_sched_in() (v2)
Date: Wed, 20 Oct 2010 15:25:01 +0200	[thread overview]
Message-ID: <4cbeeeb2.1e07e30a.317f.0daa@mx.google.com> (raw)

This is a new version of the patch to fix the way timing is handled
in group_sched_in().

Although the patch solved the issue with time_running, time_enabled
for all events in a group, it had one flaw in case the group could
never be scheduled. It would cause time_enabled to get negative.
The issue was that tstamp_stopped was never updated, even though
tstamp_enabled was.

This new version is much simpler and ensures that in case of
error in group_sched_in() during event_sched_in(), the events up
to the failed event go through regular event_sched_out(). But the
failed event and the remaining events in the group have their timings
adjusted as if they had also gone through event_sched_in() and
event_sched_out(). This ensures timing uniformity across all
events in a group. This also takes care of the tstamp_stopped problem
in case the group could never be scheduled. The tstamp_stopped is
updated as if the event had actually run.

With this patch, the following now reports correct time_enabled,
in case the NMI watchdog is active:

$ task -e unhalted_core_cycles,instructions_retired,baclears,baclears  noploop 1
noploop for 1 seconds

0 unhalted_core_cycles (100.00% scaling, ena=997,552,872, run=0)
0 instructions_retired (100.00% scaling, ena=997,552,872, run=0)
0 baclears (100.00% scaling, ena=997,552,872, run=0)
0 baclears (100.00% scaling, ena=997,552,872, run=0)

[PATCH 0/2] : introduction
[PATCH 1/2] : revert commit 8e5fc1a
[PATCH 2/2] : the actual fix

Signed-off-by: Stephane Eranian <eranian@google.com>
--

                 reply	other threads:[~2010-10-20 13:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4cbeeeb2.1e07e30a.317f.0daa@mx.google.com \
    --to=eranian@google.com \
    --cc=davem@davemloft.net \
    --cc=eranian@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=perfmon2-devel@lists.sf.net \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.com \
    /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.