[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aKaoYYm1ixYkVtyV@BLRRASHENOY1.amd.com>
Date: Thu, 21 Aug 2025 10:32:25 +0530
From: "Gautham R. Shenoy" <gautham.shenoy@....com>
To: Babu Moger <babu.moger@....com>
Cc: corbet@....net, tony.luck@...el.com, reinette.chatre@...el.com,
Dave.Martin@....com, james.morse@....com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, akpm@...ux-foundation.org,
paulmck@...nel.org, rostedt@...dmis.org, Neeraj.Upadhyay@....com,
david@...hat.com, arnd@...db.de, fvdl@...gle.com, seanjc@...gle.com,
thomas.lendacky@....com, pawan.kumar.gupta@...ux.intel.com,
yosry.ahmed@...ux.dev, sohil.mehta@...el.com, xin@...or.com,
kai.huang@...el.com, xiaoyao.li@...el.com, peterz@...radead.org,
me@...aill.net, mario.limonciello@....com, xin3.li@...el.com,
ebiggers@...gle.com, ak@...ux.intel.com, chang.seok.bae@...el.com,
andrew.cooper3@...rix.com, perry.yuan@....com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
manali.shukla@....com
Subject: Re: [PATCH v8 06/10] fs/resctrl: Add user interface to
enable/disable io_alloc feature
Hello Babu,
On Tue, Aug 05, 2025 at 06:30:26PM -0500, Babu Moger wrote:
> "io_alloc" feature in resctrl enables direct insertion of data from I/O
> devices into the cache.
>
> On AMD systems, when io_alloc is enabled, the highest CLOSID is reserved
> exclusively for I/O allocation traffic and is no longer available for
> general CPU cache allocation. Users are encouraged to enable it only when
> running workloads that can benefit from this functionality.
>
> Since CLOSIDs are managed by resctrl fs, it is least invasive to make the
> "io_alloc is supported by maximum supported CLOSID" part of the initial
> resctrl fs support for io_alloc. Take care not to expose this use of CLOSID
> for io_alloc to user space so that this is not required from other
> architectures that may support io_alloc differently in the future.
>
> Introduce user interface to enable/disable io_alloc feature.
>
> Signed-off-by: Babu Moger <babu.moger@....com>
[..snip..]
> +ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
> + size_t nbytes, loff_t off)
> +{
> + struct resctrl_schema *s = rdt_kn_parent_priv(of->kn);
> + struct rdt_resource *r = s->res;
> + char const *grp_name;
> + u32 io_alloc_closid;
> + bool enable;
> + int ret;
> +
> + ret = kstrtobool(buf, &enable);
> + if (ret)
> + return ret;
> +
> + cpus_read_lock();
> + mutex_lock(&rdtgroup_mutex);
> +
> + rdt_last_cmd_clear();
> +
> + if (!r->cache.io_alloc_capable) {
> + rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name);
> + ret = -ENODEV;
> + goto out_unlock;
> + }
> +
> + io_alloc_closid = resctrl_io_alloc_closid(r);
> + if (!resctrl_io_alloc_closid_supported(io_alloc_closid)) {
> + rdt_last_cmd_printf("io_alloc CLOSID (ctrl_hw_id) %d is not available\n",
> + io_alloc_closid);
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + /* If the feature is already up to date, no action is needed. */
> + if (resctrl_arch_get_io_alloc_enabled(r) == enable)
> + goto out_unlock;
Does it make sense to move this check before calling resctrl_io_alloc_closid(r) ?
> +
> + if (enable) {
> + if (!closid_alloc_fixed(io_alloc_closid)) {
> + grp_name = rdtgroup_name_by_closid(io_alloc_closid);
> + WARN_ON_ONCE(!grp_name);
> + rdt_last_cmd_printf("CLOSID (ctrl_hw_id) %d for io_alloc is used by %s group\n",
> + io_alloc_closid, grp_name ? grp_name : "another");
> + ret = -ENOSPC;
> + goto out_unlock;
> + }
> +
> + ret = resctrl_io_alloc_init_cbm(s, io_alloc_closid);
> + if (ret) {
> + rdt_last_cmd_puts("Failed to initialize io_alloc allocations\n");
> + closid_free(io_alloc_closid);
> + goto out_unlock;
> + }
> + } else {
> + closid_free(io_alloc_closid);
> + }
> +
> + ret = resctrl_arch_io_alloc_enable(r, enable);
> +
> +out_unlock:
> + mutex_unlock(&rdtgroup_mutex);
> + cpus_read_unlock();
> +
> + return ret ?: nbytes;
> +}
[..snip..]
--
Thanks and Regards
gautham.
Powered by blists - more mailing lists