All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: <james.morse@arm.com>, <Dave.Martin@arm.com>,
	<babu.moger@amd.com>, <bp@alien8.de>, <tglx@linutronix.de>,
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>,
	<fustini@kernel.org>, <fenghuay@nvidia.com>,
	<peternewman@google.com>, <linux-kernel@vger.kernel.org>,
	<patches@lists.linux.dev>, <christophe.jaillet@wanadoo.fr>
Subject: Re: [PATCH] fs/resctrl: Consider sparse masks when initializing new group's allocation
Date: Thu, 20 Nov 2025 14:17:44 -0800	[thread overview]
Message-ID: <fc1465ab-3df8-4272-a5a7-101887b9a82c@intel.com> (raw)
In-Reply-To: <aR9tbOMEVSDGvtoA@agluck-desk3>

Hi Tony,

On 11/20/25 11:35 AM, Luck, Tony wrote:
> On Mon, Nov 17, 2025 at 04:42:45PM -0800, Reinette Chatre wrote:
>> A new resource group is intended to be created with sane defaults. For
>> a cache resource this means all cache portions the new group could possibly
>> allocate into. This includes unused cache portions and shareable cache
>> portions used by other groups and hardware.
>>
>> New resource group creation does not take sparse masks into account. After
>> determining the bitmask reflecting the new group's possible allocations the
>> bitmask is forced to be contiguous even if the system supports sparse masks.
>> For example, a new group could by default allocate into a large portion of
>> cache represented by 0xff0f, but it is instead created with a mask of 0xf.
>>
>> Do not force a contiguous allocation range if the system supports sparse
>> masks.
> 
> Note that the allocated mask on systems that require contiguous bit allocation
> is not optimal. In your example where the available bits for the new group
> are 0xff0f, resctrl will focus on the least significant contguous range and
> set 0x000f, rather than the larger group of bits 0xff00.

Right. The priority, as supported by aptly named cbm_ensure_valid(), is to ensure
the mask can be supported by the hardware.

> 
> Fixing this would be more complex, and I don't see a lot of value as the
> user is very likley to rewrite the schemata immediatley after creating
> the new group.

I agree this can be optimized and that it is not a priority (would appreciate
to hear if there are different opinions on this). Users that may encounter
the "less than optimal" initial allocation are the ones using exclusive and/or
pseudo-locking groups where I expect user space controls allocations with care.

> 
> So for this patch as-is:
> 
> Reviewed-by: Tony Luck <tony.luck@intel.com>

Thank you very much.

Reinette


      reply	other threads:[~2025-11-20 22:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18  0:42 [PATCH] fs/resctrl: Consider sparse masks when initializing new group's allocation Reinette Chatre
2025-11-20 19:35 ` Luck, Tony
2025-11-20 22:17   ` Reinette Chatre [this message]

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=fc1465ab-3df8-4272-a5a7-101887b9a82c@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghuay@nvidia.com \
    --cc=fustini@kernel.org \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=peternewman@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@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 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.