From: Reinette Chatre <reinette.chatre@intel.com>
To: James Morse <james.morse@arm.com>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
H Peter Anvin <hpa@zytor.com>, Babu Moger <Babu.Moger@amd.com>,
<shameerali.kolothum.thodi@huawei.com>,
Jamie Iles <jamie@nuviainc.com>,
"D Scott Phillips OS" <scott@os.amperecomputing.com>,
<lcherian@marvell.com>, <bobo.shaobowang@huawei.com>
Subject: Re: [PATCH v1 11/20] x86/resctrl: Calculate bandwidth from the total bytes counter
Date: Wed, 1 Sep 2021 14:31:15 -0700 [thread overview]
Message-ID: <15febd4d-11d9-8456-60ee-994e66efdc98@intel.com> (raw)
In-Reply-To: <20210729223610.29373-12-james.morse@arm.com>
Hi James,
Apologies but I find the changelog hard to understand.
On 7/29/2021 3:36 PM, James Morse wrote:
> mbm_bw_count() maintains its own copy of prev_msr to allow it to
> calculate the bandwidth as the number of chunks counted since the
> last time mbm_bw_count() was invoked.
ok, I understand there is an extra copy
>
> The prev_msr and chunks values are in a format specific to the
> architecture. MPAM's monitor scaling can be enabled for some
> counters and not others. If the value is changed once the bandwidth
> counter passes some threshold, the prev_msr values need to be
> converted to the new scale. Having two prev_msr values is a
> hindrance to moving this logic behind an architecture specific
> function that returns the counters number of bytes.
Above talks about format ... it is not clear how it connects to
introduction where there was mention of an "extra copy"
>
> Change mbm_bw_count() to calculate the total number of bytes the
> counter has seen in the same way as __mon_event_count(), then
> calculate the bandwidth from that. prev_bw_msr is replaced by
> prev_bw_chunks, the chunks value from the last time mbm_bw_count()
> was invoked.
It is not clear to me how this change connects to either the extra copy
or the format comments. It describes the changes made but it is not
clear what the problem being solved is.
It is also not clear to me what the impact of this change on the non
software controller flow is (where data is read from user space). What
is the impact now that these two flows no longer track the previous read
value separately? Would user space still see similar data as before this
change? How would the software controller sharing control of prev_msr
affect the data?
Reinette
next prev parent reply other threads:[~2021-09-01 21:31 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 22:35 [PATCH v1 00/20] x86/resctrl: Make resctrl_arch_rmid_read() return values in bytes James Morse
2021-07-29 22:35 ` [PATCH v1 01/20] x86/resctrl: Kill off alloc_enabled James Morse
2021-08-11 12:12 ` Jamie Iles
2021-09-01 21:18 ` Reinette Chatre
2021-07-29 22:35 ` [PATCH v1 02/20] x86/resctrl: Merge mon_capable and mon_enabled James Morse
2021-08-11 12:15 ` Jamie Iles
2021-08-11 15:16 ` James Morse
2021-07-29 22:35 ` [PATCH v1 03/20] x86/resctrl: Add domain online callback for resctrl work James Morse
2021-09-01 21:19 ` Reinette Chatre
2021-09-17 16:57 ` James Morse
2021-07-29 22:35 ` [PATCH v1 04/20] x86/resctrl: Add domain offline " James Morse
2021-08-11 16:10 ` Jamie Iles
2021-09-01 21:21 ` Reinette Chatre
2021-07-29 22:35 ` [PATCH v1 05/20] x86/resctrl: Create mba_sc configuration in the rdt_domain James Morse
2021-08-11 16:32 ` Jamie Iles
2021-08-31 16:24 ` James Morse
2021-09-01 21:22 ` Reinette Chatre
2021-09-17 16:57 ` James Morse
2021-07-29 22:35 ` [PATCH v1 06/20] x86/resctrl: Switch over to the resctrl mbps_val list James Morse
2021-09-01 21:25 ` Reinette Chatre
2021-09-17 16:57 ` James Morse
2021-09-17 18:20 ` Reinette Chatre
2021-10-01 16:02 ` James Morse
2021-07-29 22:35 ` [PATCH v1 07/20] x86/resctrl: Remove architecture copy of mbps_val James Morse
2021-09-01 21:26 ` Reinette Chatre
2021-09-17 16:57 ` James Morse
2021-07-29 22:35 ` [PATCH v1 08/20] x86/resctrl: Remove set_mba_sc()s control array re-initialisation James Morse
2021-07-29 22:35 ` [PATCH v1 09/20] x86/resctrl: Abstract and use supports_mba_mbps() James Morse
2021-09-01 21:27 ` Reinette Chatre
2021-09-17 16:57 ` James Morse
2021-09-24 6:23 ` tan.shaopeng
2021-10-01 16:01 ` James Morse
2021-07-29 22:36 ` [PATCH v1 10/20] x86/resctrl: Allow update_mba_bw() to update controls directly James Morse
2021-09-01 21:28 ` Reinette Chatre
2021-07-29 22:36 ` [PATCH v1 11/20] x86/resctrl: Calculate bandwidth from the total bytes counter James Morse
2021-09-01 21:31 ` Reinette Chatre [this message]
2021-09-17 16:58 ` James Morse
2021-07-29 22:36 ` [PATCH v1 12/20] x86/recstrl: Add per-rmid arch private storage for overflow and chunks James Morse
2021-08-11 17:14 ` Jamie Iles
2021-08-31 16:25 ` James Morse
2021-07-29 22:36 ` [PATCH v1 13/20] x86/recstrl: Allow per-rmid arch private storage to be reset James Morse
2021-09-24 6:34 ` tan.shaopeng
2021-10-01 16:01 ` James Morse
2021-07-29 22:36 ` [PATCH v1 14/20] x86/resctrl: Abstract __rmid_read() James Morse
2021-07-29 22:36 ` [PATCH v1 15/20] x86/resctrl: Pass the required parameters into resctrl_arch_rmid_read() James Morse
2021-07-29 22:36 ` [PATCH v1 16/20] x86/resctrl: Move mbm_overflow_count() " James Morse
2021-07-29 22:36 ` [PATCH v1 17/20] x86/resctrl: Move get_corrected_mbm_count() " James Morse
2021-07-29 22:36 ` [PATCH v1 18/20] x86/resctrl: Rename and change the units of resctrl_cqm_threshold James Morse
2021-07-29 22:36 ` [PATCH v1 19/20] x86/resctrl: Add resctrl_rmid_realloc_limit to abstract x86's boot_cpu_data James Morse
2021-07-29 22:36 ` [PATCH v1 20/20] x86/resctrl: Make resctrl_arch_rmid_read() return values in bytes James Morse
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=15febd4d-11d9-8456-60ee-994e66efdc98@intel.com \
--to=reinette.chatre@intel.com \
--cc=Babu.Moger@amd.com \
--cc=bobo.shaobowang@huawei.com \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jamie@nuviainc.com \
--cc=lcherian@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=scott@os.amperecomputing.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--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;
as well as URLs for NNTP newsgroup(s).