From: Robert Richter <robert.richter@amd.com>
To: Maynard Johnson <maynardj@us.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
oprofile-list <oprofile-list@lists.sourceforge.net>,
William Cohen <wcohen@redhat.com>,
"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@amd.com>
Subject: Re: [PATCH] oprofile: disable write access to oprofilefs while profiler is running
Date: Mon, 11 Oct 2010 17:39:42 +0200 [thread overview]
Message-ID: <20101011153942.GU13563@erda.amd.com> (raw)
In-Reply-To: <4CB31592.2080508@us.ibm.com>
On 11.10.10 09:48:02, Maynard Johnson wrote:
> Robert, I don't have any issue with this patch except I'm not sure what problem
> it's fixing. From my read of oprofile userland code, I don't see where
> profiling parameters are ever written to oprofilefs when profiling is active.
> Is your patch intended to guard against potential non-intentional cases
> occurring in userland code? Or is there some case existing right now?
The kernel updates the counter configuration during profiling only
when the counters are started. Since sampling data and its
representation depends on the counter configuration, we do not want to
change the configuration in-flight. Otherwise the daemon may not know
which configuration was used for which sample.
Instead, userland is required to restart profiling which also flushes
cpu buffers. Thus, the daemon always is aware of the configuration
which was used when the kernel wrote a sample.
This may happen e.g. for IBS samples, where certain options may be
enabled using oprofilefs. We want to know which options are set while
a sample is written and make sure, the options do not change. There is
another case, the latest patch I sent that implements IBS branch
target address reporting extends the IBS sample size if its option is
set. To always proper parse the sampling data by the daemon, we must
ensure the sampling data is consistent over one profiling session and
sample size does not change.
As we rely on not writing to the configuration while profiling and
since this works with the current daemon, I added the check.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
next prev parent reply other threads:[~2010-10-11 15:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-05 10:36 [PATCH] oprofile: disable write access to oprofilefs while profiler is running Robert Richter
2010-10-05 10:42 ` Robert Richter
2010-10-05 16:33 ` Robert Richter
2010-10-11 13:48 ` Maynard Johnson
2010-10-11 15:39 ` Robert Richter [this message]
2010-10-12 15:11 ` Maynard Johnson
2010-10-12 15:33 ` Robert Richter
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=20101011153942.GU13563@erda.amd.com \
--to=robert.richter@amd.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maynardj@us.ibm.com \
--cc=oprofile-list@lists.sourceforge.net \
--cc=wcohen@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox