All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"Wieczor-Retman, Maciej" <maciej.wieczor-retman@intel.com>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	"shuah@kernel.org" <shuah@kernel.org>
Cc: "linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ilpo.jarvinen@linux.intel.com" <ilpo.jarvinen@linux.intel.com>
Subject: Re: [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size with SNC enabled
Date: Fri, 31 May 2024 09:17:46 -0700	[thread overview]
Message-ID: <07325558-c816-42ec-9f74-464df2f98e9f@intel.com> (raw)
In-Reply-To: <SJ1PR11MB60835941880FC77E1B1E9FEFFCFC2@SJ1PR11MB6083.namprd11.prod.outlook.com>


Hi Tony and Maciej,

On 5/30/24 5:34 PM, Luck, Tony wrote:
>>>>> 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.

Thanks Tony. I trust that this is what Maciej intended since the change
is specifically named "Adjuct _effective_ L3 cache size". I'd like to
recommend that your comments be added before the change to
get_cache_size() ...

	/*
	 * 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.
	 * E.g. on a SNC-2 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.
	 */

Reinette

  reply	other threads:[~2024-05-31 16:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15 11:17 [PATCH v2 0/2] selftests/resctrl: SNC kernel support discovery Maciej Wieczor-Retman
2024-05-15 11:18 ` [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size with SNC enabled Maciej Wieczor-Retman
2024-05-15 16:48   ` Luck, Tony
2024-05-16  6:01     ` Maciej Wieczor-Retman
2024-05-30 23:07   ` Reinette Chatre
2024-05-30 23:46     ` Luck, Tony
2024-05-30 23:51       ` Reinette Chatre
2024-05-31  0:34         ` Luck, Tony
2024-05-31 16:17           ` Reinette Chatre [this message]
2024-06-25 11:04     ` Maciej Wieczor-Retman
2024-06-25 16:28       ` Reinette Chatre
2024-06-26  7:09         ` Maciej Wieczor-Retman
2024-06-26 16:46           ` Reinette Chatre
2024-06-27  9:50             ` Maciej Wieczor-Retman
2024-06-27 16:30               ` Reinette Chatre
2024-06-28  7:52                 ` Maciej Wieczor-Retman
2024-05-15 11:18 ` [PATCH v2 2/2] selftests/resctrl: Adjust SNC support messages Maciej Wieczor-Retman
2024-05-30 23:07   ` Reinette Chatre
2024-05-31  6:39     ` Maciej Wieczor-Retman

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=07325558-c816-42ec-9f74-464df2f98e9f@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=shuah@kernel.org \
    --cc=tony.luck@intel.com \
    /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.