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: <SJ1PR11MB60835941880FC77E1B1E9FEFFCFC2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 31 May 2024 00:34:03 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Chatre, Reinette" <reinette.chatre@...el.com>, "Wieczor-Retman, Maciej"
	<maciej.wieczor-retman@...el.com>, "Yu, Fenghua" <fenghua.yu@...el.com>,
	"shuah@...nel.org" <shuah@...nel.org>
CC: "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>
Subject: RE: [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size
 with SNC enabled

> >>> When SNC mode is enabled the effective amount of L3 cache available
> >>> for allocation is divided by the number of nodes per L3.
> >>
> >> This was a mistake in original implementation and no longer done.
> >
> > My original kernel code adjusted value reported in the "size" file in resctrl.
> > That's no longer done because the effective size depends on how applications
> > are allocating and using memory. Since the kernel can't know that, it
> > seemed best to just report the total size of the cache.
> >
> > But I think the resctrl tests still need to take this into account when running
> > llc_occupancy tests.
> >
> > E.g. on a 2-way SNC system with a 100MB L3 cache a test that allocates
> > memory from its local SNC node (default behavior without using libnuma)
> > will only see 50 MB llc_occupancy with a fully populated L3 mask in the
> > schemata file.
>
> This seems to contradict the "Cache and memory bandwidth allocation features
> continue to operate at the scope of the L3 cache." statement from [1]?

I'll clean that up. MBA isn't affected. But cache allocation is affected in that
the amount of cache represented by each bit in the masks in the schemata
file is reduced by a factor equal to SNC nodes per L3 cache.

-Tony
>
> Reinette
>
> [1] https://lore.kernel.org/lkml/20240528222006.58283-1-tony.luck@intel.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ