From: Andi Kleen <andi@firstfloor.org>
To: Shivappa Vikas <vikas.shivappa@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Vikas Shivappa <vikas.shivappa@linux.intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
ravi.v.shankar@intel.com, tony.luck@intel.com,
fenghua.yu@intel.com, davidcc@google.com, eranian@google.com,
hpa@zytor.com
Subject: Re: [PATCH 01/14] x86/cqm: Intel Resource Monitoring Documentation
Date: Tue, 27 Dec 2016 12:00:11 -0800 [thread overview]
Message-ID: <87vau5gn1w.fsf@firstfloor.org> (raw)
In-Reply-To: <alpine.DEB.2.10.1612241747170.32409@vshiva-Udesk> (Shivappa Vikas's message of "Sat, 24 Dec 2016 17:51:14 -0800 (PST)")
Shivappa Vikas <vikas.shivappa@intel.com> writes:
>
> Ok , looks like the interface is the problem. Will try to fix
> this. We are just trying to have a light weight monitoring
> option so that its reasonable to monitor for a
> very long time (like lifetime of process etc). Mainly to not have all
> the perf scheduling overhead.
That seems like an odd reason to define a completely new user interface.
This is to avoid one MSR write for a RMID change per context switch
in/out cgroup or is it other code too?
Is there some number you can put to the overhead?
Or is there some other overhead other than the MSR write
you're concerned about?
Do you have an ftrace or better PT trace with the overhead before-after?
Perhaps some optimization could be done in the code to make it faster,
then the new interface wouldn't be needed.
FWIW there are some pending changes to context switch that will
eliminate at least one common MSR write [1]. If that was fixed
you could do the RMID MSR write "for free"
-Andi
[1] https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/fsgsbase
next prev parent reply other threads:[~2016-12-27 20:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-16 23:12 [PATCH V4 00/14] Cqm2: Intel Cache Monitoring fixes and enhancements Vikas Shivappa
2016-12-16 23:12 ` [PATCH 01/14] x86/cqm: Intel Resource Monitoring Documentation Vikas Shivappa
2016-12-23 12:32 ` Peter Zijlstra
2016-12-23 19:35 ` Shivappa Vikas
2016-12-23 20:33 ` Peter Zijlstra
2016-12-23 21:41 ` Shivappa Vikas
2016-12-25 1:51 ` Shivappa Vikas
2016-12-27 7:13 ` David Carrillo-Cisneros
2016-12-27 20:00 ` Andi Kleen [this message]
2016-12-27 20:21 ` Shivappa Vikas
2016-12-27 21:38 ` David Carrillo-Cisneros
2016-12-27 21:33 ` David Carrillo-Cisneros
2016-12-27 23:10 ` Andi Kleen
2016-12-28 1:23 ` David Carrillo-Cisneros
2016-12-28 20:03 ` Shivappa Vikas
2016-12-16 23:12 ` [PATCH 02/14] x86/cqm: Remove cqm recycling/conflict handling Vikas Shivappa
2016-12-16 23:12 ` [PATCH 03/14] x86/rdt: Add rdt common/cqm compile option Vikas Shivappa
2016-12-16 23:12 ` [PATCH 04/14] x86/cqm: Add Per pkg rmid support Vikas Shivappa
2016-12-16 23:12 ` [PATCH 05/14] x86/cqm,perf/core: Cgroup support prepare Vikas Shivappa
2016-12-16 23:13 ` [PATCH 06/14] x86/cqm: Add cgroup hierarchical monitoring support Vikas Shivappa
2016-12-16 23:13 ` [PATCH 07/14] x86/rdt,cqm: Scheduling support update Vikas Shivappa
2016-12-16 23:13 ` [PATCH 08/14] x86/cqm: Add support for monitoring task and cgroup together Vikas Shivappa
2016-12-16 23:13 ` [PATCH 09/14] x86/cqm: Add Continuous cgroup monitoring Vikas Shivappa
2016-12-16 23:13 ` [PATCH 10/14] x86/cqm: Add RMID reuse Vikas Shivappa
2016-12-16 23:13 ` [PATCH 11/14] x86/cqm: Add failure on open and read Vikas Shivappa
2016-12-23 11:58 ` David Carrillo-Cisneros
2016-12-16 23:13 ` [PATCH 12/14] perf/core,x86/cqm: Add read for Cgroup events,per pkg reads Vikas Shivappa
2016-12-16 23:13 ` [PATCH 13/14] perf/stat: fix bug in handling events in error state Vikas Shivappa
2016-12-16 23:13 ` [PATCH 14/14] perf/stat: revamp read error handling, snapshot and per_pkg events Vikas Shivappa
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=87vau5gn1w.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=davidcc@google.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vikas.shivappa@intel.com \
--cc=vikas.shivappa@linux.intel.com \
--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 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.