linux-kernel - RE: [PATCH v9 4/9] x86/resctrl: Compute memory bandwidth for all supported events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <SJ1PR11MB60833AE650A03028470CAA86FC242@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 15 Nov 2024 16:59:47 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Peter Newman <peternewman@...gle.com>
CC: "Yu, Fenghua" <fenghua.yu@...el.com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, Jonathan Corbet <corbet@....net>,
	"x86@...nel.org" <x86@...nel.org>, James Morse <james.morse@....com>, "Jamie
 Iles" <quic_jiles@...cinc.com>, Babu Moger <babu.moger@....com>, Randy Dunlap
	<rdunlap@...radead.org>, "Shaopeng Tan (Fujitsu)" <tan.shaopeng@...itsu.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH v9 4/9] x86/resctrl: Compute memory bandwidth for all
 supported events

> I experimented with all-groups, per-domain counter aggregation files
> prototype using this change as a starting point.
>
> I'm happy to report that the values reported looked fairly reasonable.
>
> Tested-by: Peter Newman <peternewman@...gle.com>

Thanks for the test report.

> On an AMD EPYC 7B12 64-Core Processor, I saw a consistent 1.021-1.026
> second period. Is this enough error that you would want to divide by
> the actual period instead of assuming a denominator of 1 exactly?
> We're mainly concerned with the relative bandwidth of jobs, so this
> error isn't much concern as long as it doesn't favor any group.

I see pretty much the same delta_t on Intel Icelake. We could
use jiffies to get a bit more precision (depending on HZ value).

> The only thing I'd worry about is if the user is using setitimer() to
> keep a consistent 1 second period for reading the bandwidth rate, the
> window of the resctrl updates would drift away from the userspace
> consumer over time.

One other thing I did in my resctrl2 summary code was to patch
the modification time of the summary file to when the kernel ran
mbm_handle_overflow(). That would allow users to check the
update time to stay in sync with kernel updates.

-Tony