From: Reinette Chatre <reinette.chatre@intel.com>
To: Drew Fustini <fustini@kernel.org>
Cc: "Adrien Ricciardi" <aricciardi@baylibre.com>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Atish Kumar Patra" <atishp@rivosinc.com>,
"Atish Patra" <atish.patra@linux.dev>,
"Babu Moger" <babu.moger@amd.com>,
"Ben Horgan" <ben.horgan@arm.com>,
"Borislav Petkov" <bp@alien8.de>,
"Chen Pei" <cp0613@linux.alibaba.com>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Conor Dooley" <conor+dt@kernel.org>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Dave Martin" <Dave.Martin@arm.com>,
"Fenghua Yu" <fenghuay@nvidia.com>,
"Gong Shuai" <gong.shuai@sanechips.com.cn>,
"Gong Shuai" <gsh517@gmail.com>,
guo.wenjia23@zte.com.cn, "James Morse" <james.morse@arm.com>,
"Kornel Dulęba" <mindal@semihalf.com>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
liu.qingtao2@zte.com.cn,
"Liu Zhiwei" <zhiwei_liu@linux.alibaba.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paul Walmsley" <pjw@kernel.org>,
"Peter Newman" <peternewman@google.com>,
"Radim Krčmář" <rkrcmar@ventanamicro.com>,
"Rob Herring" <robh@kernel.org>,
"Samuel Holland" <samuel.holland@sifive.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Tony Luck" <tony.luck@intel.com>,
"Vasudevan Srinivasan" <vasu@rivosinc.com>,
"Ved Shanbhogue" <ved@rivosinc.com>,
"Weiwei Li" <liwei1518@gmail.com>,
"yunhui cui" <cuiyunhui@bytedance.com>,
"Zhanpeng Zhang" <zhangzhanpeng.jasper@bytedance.com>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
x86@kernel.org, devicetree@vger.kernel.org,
linux-rt-devel@lists.linux.dev, linux-doc@vger.kernel.org
Subject: Re: [PATCH v7 2/5] riscv_cbqri: resctrl: Add cache allocation via capacity block mask
Date: Thu, 17 Sep 2026 09:27:42 -0700 [thread overview]
Message-ID: <76048b44-8faf-4fc1-a265-478ad83ff7b8@intel.com> (raw)
In-Reply-To: <aqwS7qgGNkSHxoSz@gen8>
Hi Drew,
On 9/17/26 9:18 AM, Drew Fustini wrote:
> On Thu, Sep 17, 2026 at 08:37:43AM -0700, Reinette Chatre wrote:
>> On 9/1/26 3:31 PM, Drew Fustini wrote:
>>> resctrl exposes a single cap set per rid, so when more than one capacity
>>> controller backs a cache level they must agree on those caps. A level
>>> whose controllers disagree is left unexposed. Other levels are
>>> unaffected.
>> If I understand correctly, while attempting to translate to resctrl terms,
>> this means that a cache resource with several domains may support different
>> capacity masks in the domains?
>
> Yes, each capacity controller reports its own number of capacity blocks,
> so two controllers backing the same cache level can have different
> maximum capacity masks.
Thank you.
>
>> I believe the "single cap set per rid" you refer to is
>> /sys/fs/resctrl/info/L3/cbm_mask and /sys/fs/resctrl/info/L2/cbm_mask that
>> exposes a single capacity bitmask representing the maximum allocation.
>>
>> As you know, resctrl is in the process of changing the way in which schema
>> formats are described. The most recent PoC [1] added new bitmap description
>> files but it kept a single value "max" file to describe the highest allocation
>> possible for a bitmap schema.
>>
>> To support asymmetrical cache instances it looks like changing the interface
>> to describe the maximum per domain (instead of one global value) could address
>> the gap?
>>
>> For example, if there is a hypothetical system with two L2 cache instances, one
>> with a 0xFF max CBM and the other with a 0XF max CBM then resctrl could expose it
>> as:
>>
>> # cat /sys/fs/resctrl/info/L2/schemata/L2/max
>> 0=ff;1=f
>>
>> The schemata file currently and will continue to display the allocations per domain.
>>
>> resctrl will need more changes to support different CBM per domain internally and
>> until then all these CBMs will be the same, but adding this change to user interface now
>> may set resctrl up to support these systems in the future?
>
> I think that would be a good change to the generic schema rfc as a max
> per domain would be helpful for CBQRI. The hardware I am working with
Will do.
> right now (Tenstorrent Ascalon) does not have two controllers at one
> level, but I think it is reasonable to assume other RISC-V platforms may
> do that in the future.
Looking at this patch more it seems the controllers could also differ in
CDP ("supports_alloc_at_code") support. Supporting that in resctrl is a
different story.
> BTW, I have been meaning to send v8 with some unrelated minor
> improvements based on sashiko comments in v7. I will go ahead and send
> right now in case you are looking at the rest of the series.
That is fine. I just started looking at v7 and will switch to v8 instead.
Thank you.
Reinette
next prev parent reply other threads:[~2026-09-17 16:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 22:31 [PATCH v7 0/5] riscv: Add Ssqosid and initial CBQRI resctrl support Drew Fustini
2026-09-01 22:31 ` [PATCH v7 1/5] riscv_cbqri: Add capacity controller probe and allocation device ops Drew Fustini
2026-09-01 22:42 ` sashiko-bot
2026-09-01 22:31 ` [PATCH v7 2/5] riscv_cbqri: resctrl: Add cache allocation via capacity block mask Drew Fustini
2026-09-17 15:37 ` Reinette Chatre
2026-09-17 15:57 ` Luck, Tony
2026-09-17 16:18 ` Drew Fustini
2026-09-17 16:27 ` Reinette Chatre [this message]
2026-09-01 22:31 ` [PATCH v7 3/5] riscv: Enable resctrl filesystem for Ssqosid Drew Fustini
2026-09-01 22:31 ` [PATCH v7 4/5] dt-bindings: riscv: Add binding for CBQRI controllers Drew Fustini
2026-09-01 22:31 ` [PATCH v7 5/5] riscv_cbqri: Add CBQRI capacity allocation platform driver Drew Fustini
2026-09-03 3:24 ` [PATCH v7 0/5] riscv: Add Ssqosid and initial CBQRI resctrl support Chen Pei
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=76048b44-8faf-4fc1-a265-478ad83ff7b8@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=alex@ghiti.fr \
--cc=aricciardi@baylibre.com \
--cc=atish.patra@linux.dev \
--cc=atishp@rivosinc.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=cp0613@linux.alibaba.com \
--cc=cuiyunhui@bytedance.com \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=fenghuay@nvidia.com \
--cc=fustini@kernel.org \
--cc=gong.shuai@sanechips.com.cn \
--cc=gsh517@gmail.com \
--cc=guo.wenjia23@zte.com.cn \
--cc=james.morse@arm.com \
--cc=krzk+dt@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=liu.qingtao2@zte.com.cn \
--cc=liwei1518@gmail.com \
--cc=mindal@semihalf.com \
--cc=palmer@dabbelt.com \
--cc=peternewman@google.com \
--cc=pjw@kernel.org \
--cc=rkrcmar@ventanamicro.com \
--cc=robh@kernel.org \
--cc=samuel.holland@sifive.com \
--cc=tony.luck@intel.com \
--cc=vasu@rivosinc.com \
--cc=ved@rivosinc.com \
--cc=x86@kernel.org \
--cc=zhangzhanpeng.jasper@bytedance.com \
--cc=zhiwei_liu@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®