From: Peter Zijlstra <peterz@infradead.org>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: vikas.shivappa@intel.com, linux-kernel@vger.kernel.org,
x86@kernel.org, hpa@zytor.com, tglx@linutronix.de,
mingo@kernel.org, ravi.v.shankar@intel.com, tony.luck@intel.com,
fenghua.yu@intel.com, h.peter.anvin@intel.com
Subject: Re: [PATCH 4/6] x86/mbm: Memory bandwidth monitoring event management
Date: Tue, 8 Mar 2016 00:03:29 +0100 [thread overview]
Message-ID: <20160307230329.GT6344@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1456876108-28770-5-git-send-email-vikas.shivappa@linux.intel.com>
On Tue, Mar 01, 2016 at 03:48:26PM -0800, Vikas Shivappa wrote:
> Lot of the scheduling code was taken out from Tony's patch and a 3-4
> lines of change were added in the intel_cqm_event_read. Since the timer
> is no more added on every context switch this change was made.
It this here to confuse people or is there some actual information in
it?
> +/*
> + * MBM Counter is 24bits wide. MBM_CNTR_MAX defines max counter
> + * value
> + */
> +#define MBM_CNTR_MAX 0xffffff
#define MBM_CNTR_WIDTH 24
#define MBM_CNTR_MAX ((1U << MBM_CNTR_WIDTH) - 1)
> #define QOS_L3_OCCUP_EVENT_ID (1 << 0)
> +/*
> + * MBM Event IDs as defined in SDM section 17.15.5
> + * Event IDs are used to program EVTSEL MSRs before reading mbm event counters
> + */
> +enum mbm_evt_type {
> + QOS_MBM_TOTAL_EVENT_ID = 0x02,
> + QOS_MBM_LOCAL_EVENT_ID,
> + QOS_MBM_TOTAL_BW_EVENT_ID,
> + QOS_MBM_LOCAL_BW_EVENT_ID,
> +};
QOS_L3_*_EVENT_ID is a define, these are an enum. Rather inconsistent.
> struct rmid_read {
> u32 rmid;
Hole, you could've filled with the enum (which ends up being an int I
think).
> atomic64_t value;
> + enum mbm_evt_type evt_type;
> };
> +static bool is_mbm_event(int e)
You had an enum type, you might as well use it.
> +{
> + return (e >= QOS_MBM_TOTAL_EVENT_ID && e <= QOS_MBM_LOCAL_BW_EVENT_ID);
> +}
>
> +static struct sample *update_sample(unsigned int rmid,
> + enum mbm_evt_type evt_type, int first)
> +{
> + ktime_t cur_time;
> + struct sample *mbm_current;
> + u32 vrmid = rmid_2_index(rmid);
> + u64 val, bytes, diff_time;
> + u32 eventid;
> +
> + if (evt_type & QOS_MBM_LOCAL_EVENT_MASK) {
> + mbm_current = &mbm_local[vrmid];
> + eventid = QOS_MBM_LOCAL_EVENT_ID;
> + } else {
> + mbm_current = &mbm_total[vrmid];
> + eventid = QOS_MBM_TOTAL_EVENT_ID;
> + }
> +
> + cur_time = ktime_get();
> + wrmsr(MSR_IA32_QM_EVTSEL, eventid, rmid);
> + rdmsrl(MSR_IA32_QM_CTR, val);
> + if (val & (RMID_VAL_ERROR | RMID_VAL_UNAVAIL))
> + return mbm_current;
> + val &= MBM_CNTR_MAX;
> + if (val < mbm_current->prev_msr)
> + bytes = MBM_CNTR_MAX - mbm_current->prev_msr + val + 1;
> + else
> + bytes = val - mbm_current->prev_msr;
Would not something like:
shift = 64 - MBM_CNTR_WIDTH;
bytes = (val << shift) - (prev << shift);
bytes >>= shift;
be less obtuse? (and consistent with how every other perf update
function does it).
What guarantee is there we didn't wrap multiple times? Doesn't that
deserve a comment?
> + bytes *= cqm_l3_scale;
> +
> + mbm_current->total_bytes += bytes;
> + mbm_current->interval_bytes += bytes;
> + mbm_current->prev_msr = val;
> + diff_time = ktime_ms_delta(cur_time, mbm_current->interval_start);
Here we do a / 1e6
> +
> + /*
> + * The b/w measured is really the most recent/current b/w.
> + * We wait till enough time has passed to avoid
> + * arthmetic rounding problems.Having it at >=100ms,
> + * such errors would be <=1%.
> + */
> + if (diff_time > 100) {
This could well be > 100e6 instead, avoiding the above division most of
the time.
> + bytes = mbm_current->interval_bytes * MSEC_PER_SEC;
> + do_div(bytes, diff_time);
> + mbm_current->bandwidth = bytes;
> + mbm_current->interval_bytes = 0;
> + mbm_current->interval_start = cur_time;
> + }
> +
> + return mbm_current;
> +}
How does the above time tracking deal with the event not actually having
been scheduled the whole time?
> +static void init_mbm_sample(u32 rmid, enum mbm_evt_type evt_type)
> +{
> + struct rmid_read rr = {
> + .value = ATOMIC64_INIT(0),
> + };
> +
> + rr.rmid = rmid;
> + rr.evt_type = evt_type;
That's just sad.. put those two in the struct init as well.
> + /* on each socket, init sample */
> + on_each_cpu_mask(&cqm_cpumask, __intel_mbm_event_init, &rr, 1);
> +}
next prev parent reply other threads:[~2016-03-07 23:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 23:48 [PATCH V5 0/6] Intel memory b/w monitoring support Vikas Shivappa
2016-03-01 23:48 ` [PATCH 1/6] x86,perf/cqm: Fix cqm handling of grouping events into a cache_group Vikas Shivappa
2016-03-07 23:04 ` Peter Zijlstra
2016-03-10 0:18 ` Vikas Shivappa
2016-03-01 23:48 ` [PATCH 2/6] x86,perf/cqm: Fix cqm memory leak and notifier leak Vikas Shivappa
2016-03-02 8:00 ` Thomas Gleixner
2016-03-02 17:58 ` Vikas Shivappa
2016-03-02 23:53 ` Vikas Shivappa
2016-03-08 9:22 ` Thomas Gleixner
2016-03-08 19:36 ` Vikas Shivappa
2016-03-01 23:48 ` [PATCH 3/6] x86/mbm: Intel Memory B/W Monitoring enumeration and init Vikas Shivappa
2016-03-02 8:04 ` Thomas Gleixner
2016-03-02 17:59 ` Vikas Shivappa
2016-03-02 21:31 ` Vikas Shivappa
2016-03-02 23:56 ` Vikas Shivappa
2016-03-03 7:35 ` Thomas Gleixner
2016-03-03 18:26 ` Vikas Shivappa
2016-03-03 18:37 ` Thomas Gleixner
2016-03-08 9:25 ` Thomas Gleixner
2016-03-08 19:36 ` Vikas Shivappa
2016-03-01 23:48 ` [PATCH 4/6] x86/mbm: Memory bandwidth monitoring event management Vikas Shivappa
2016-03-07 23:03 ` Peter Zijlstra [this message]
2016-03-07 23:27 ` Luck, Tony
2016-03-08 8:49 ` Peter Zijlstra
2016-03-10 22:46 ` Vikas Shivappa
2016-03-10 22:49 ` Vikas Shivappa
2016-03-01 23:48 ` [PATCH 5/6] x86/mbm: RMID Recycling MBM changes Vikas Shivappa
2016-03-01 23:48 ` [PATCH 6/6] x86/mbm: Add support for MBM counter overflow handling Vikas Shivappa
2016-03-02 23:58 ` Vikas Shivappa
2016-03-10 23:32 [PATCH V6 0/6] Intel memory b/w monitoring support Vikas Shivappa
2016-03-10 23:32 ` [PATCH 4/6] x86/mbm: Memory bandwidth monitoring event management Vikas Shivappa
2016-03-11 19:26 ` Tony Luck
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=20160307230329.GT6344@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=fenghua.yu@intel.com \
--cc=h.peter.anvin@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome