From: "Luck, Tony" <tony.luck@intel.com>
To: <alex@ghiti.fr>, <aou@eecs.berkeley.edu>, <babu.moger@amd.com>,
<baolin.wang@linux.alibaba.com>, <ben.horgan@arm.com>,
<corbet@lwn.net>, <cuiyunhui@bytedance.com>,
<Dave.Martin@arm.com>, <fustini@kernel.org>,
<james.morse@arm.com>, <jgg@ziepe.ca>, <joro@8bytes.org>,
<kevin.tian@intel.com>, <palmer@dabbelt.com>, <pjw@kernel.org>,
<reinette.chatre@intel.com>, <robin.murphy@arm.com>,
<shuah@kernel.org>, <tomasz.jeznach@linux.dev>,
<tony.luck@intel.com>, <wangzhou1@hisilicon.com>,
<will@kernel.org>, <xiaqinxin@huawei.com>,
<yuanzhu@bytedance.com>, <zengheng4@huawei.com>,
<zhangzhanpeng.jasper@bytedance.com>
Cc: <x86@kernel.org>, <iommu@lists.linux.dev>, <linuxarm@huawei.com>,
<linux-kernel@vger.kernel.org>, <linux-riscv@lists.infradead.org>
Subject: Resctrl and I/O
Date: Tue, 22 Sep 2026 09:51:11 -0700 [thread overview]
Message-ID: <arKx__kOPe4B5gDW@agluck-desk3> (raw)
Patches for ARM[1] and RISC-V[2] are both at RFC status.
They appear to be based on similar h/w capabilities where architecture
specific tags can be added to transactions from I/O devices by the IOMMU
servicing the device. Device enumeration is handled outside of the resctrl
file system.
ARM docs say "the device name is the one listed under /sys/kernel/iommu_groups/<id>/devices/"
RISC-V says architecture specific device tokens are "devices or device groups"
In both cases assignments are made with:
# echo {device} > {group}/devices
So now I'm looking at the capabilities of Intel RDT hardware. I'm ignoring
the implementation on the Granite Rapids CPU, and looking at what is described
in the RDT Architecture Specification[3]. Here are the highlights:
1) Enumeration is split between two ACPI tables. IRDT enumerates device groups
and provides MMIO addresses to assign CLOSID/RMID to each group. ERDT provides
MMIO addresses to read event counts for RMIDs and to configure cache allocation
bit masks and memory bandwidth limits.
2) All I/O monitoring and control is with respect to I/O caches, not to the L3
caches that legacy RDT features operate on.
3) The number of RMIDs supported for I/O is lower (maybe considearbly lower)
than the number supported for CPU monitoring.
4) Monitoring events are I/O cache occupancy, total i/o bandwidth, and i/o miss
bandwidth.
5) Current revision (1.4) of the specification doesn't include details of
I/O memory bandwidth control (The "IBAD" subtable of ERDT is reserved for this).
Fitting this into resctrl
-------------------------
RISC-V description of "architecture specific device tokens" sounds great.
I'll have to find some ares of /sys to provide the mapping of tokens to
"device groups". There's no association with IOMMUs, so this will be some
other path in /sys. Perhaps under /sys/firmware/acpi since the data comes
from ACPI IRDT table.
Need an info file to tell users the format and source for device tokens.
I'd like to avoid limiting resctrl monitoring of CPU activity due to the small
number of I/O RMIDs. Perhaps don't include a "devices" file or mon_data/{i/o
events} files in resctrl group directories when rdtgroup::mon::rmid >=
num_io_rmids? But that feels clumsy.
Domains are based on I/O L3 cache instances. So a new rdt_resource with
new line in the schemata file for IOL3 cache masks per domain. In the
future when there are I/O MBA controls, new line(s) for those too.
-Tony
[1] https://lore.kernel.org/linux-iommu/20260901140802.1215508-1-xiaqinxin@huawei.com/
[2] https://lore.kernel.org/lkml/20260714130657.46963-1-zhangzhanpeng.jasper@bytedance.com/
[3] Linked from the bottom of https://www.intel.com/sdm under "Related Specifications", or
direct link: https://cdrdv2.intel.com/v1/dl/getContent/789566?erpm_id=1158389_ts1790091453223
next reply other threads:[~2026-09-22 16:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 16:51 Luck, Tony [this message]
2026-09-23 1:27 ` Drew Fustini
2026-09-23 17:13 ` James Morse
2026-09-23 17:24 ` Jason Gunthorpe
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=arKx__kOPe4B5gDW@agluck-desk3 \
--to=tony.luck@intel.com \
--cc=Dave.Martin@arm.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=babu.moger@amd.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=ben.horgan@arm.com \
--cc=corbet@lwn.net \
--cc=cuiyunhui@bytedance.com \
--cc=fustini@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=james.morse@arm.com \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=reinette.chatre@intel.com \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=tomasz.jeznach@linux.dev \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xiaqinxin@huawei.com \
--cc=yuanzhu@bytedance.com \
--cc=zengheng4@huawei.com \
--cc=zhangzhanpeng.jasper@bytedance.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®