Re: [PATCH 1/2] uacce: add device usage sysfs interface
From: Weili Qian
Date: Tue Sep 22 2026 - 09:36:28 EST
On 2026/9/22 20:13, Greg KH wrote:
On Tue, Sep 22, 2026 at 07:57:14PM +0800, Weili Qian wrote:
Then that can not be a sysfs file, as sysfs files are "one value per
On 2026/9/22 17:21, Greg KH wrote:
On Tue, Sep 22, 2026 at 05:11:55PM +0800, qianweili wrote:A single device may run multiple independent algorithms in parallel
On 2026/9/21 16:12, Greg KH wrote:Then that is going to be a mess, sysfs files should be in a consistant
On Mon, Sep 21, 2026 at 03:51:30PM +0800, Weili Qian wrote:I'll change it to 7.4 in the next version.
Userspace has no way to query the runtime usage of a UACCEThat's not going to happen here :(
device; it can only be inferred indirectly from queue state, which is
neither accurate nor uniform across drivers.
Add a read-only dev_usage sysfs attribute and a get_dev_usage callback
in struct uacce_ops. A driver implementing the callback writes the
current usage as a percentage (0-100) string into the caller-provided
buffer and returns the number of bytes written; dev_usage_show()
appends the trailing newline. The attribute is hidden via
uacce_dev_is_visible() when the driver does not provide the callback.
The corresponding ABI entry is added to Documentation/ABI/testing/
sysfs-driver-uacce.
Signed-off-by: Weili Qian <qianweili@xxxxxxxxxx>
---
Documentation/ABI/testing/sysfs-driver-uacce | 9 +++++++++
drivers/misc/uacce/uacce.c | 19 +++++++++++++++++++
include/linux/uacce.h | 5 +++++
3 files changed, 33 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-uacce b/Documentation/ABI/testing/sysfs-driver-uacce
index d3f0b8f3c589..3e4af4c1e5a9 100644
--- a/Documentation/ABI/testing/sysfs-driver-uacce
+++ b/Documentation/ABI/testing/sysfs-driver-uacce
@@ -55,3 +55,12 @@ Date: Feb 2020
KernelVersion: 5.7
Contact: linux-accelerators@xxxxxxxxxxxxxxxx
Description: Size (bytes) of dus region queue file
+
+What: /sys/class/uacce/<dev_name>/dev_usage
+Date: Sep 2026
+KernelVersion: 7.3
sysfs_emit() is useful when the framework side knows the format string+Contact: linux-accelerators@xxxxxxxxxxxxxxxxWhy can't you use sysfs_emit()? That way you don't have to worry about
+Description: (R) Current usage of the device, reported as a driver-defined
+ string of up to PAGE_SIZE - 1 bytes. Usage is expressed as a
+ percentage (0-100). The attribute is hidden if the driver does
+ not implement the get_dev_usage callback.
diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c
index 45521d4a56d1..545ba35a590b 100644
--- a/drivers/misc/uacce/uacce.c
+++ b/drivers/misc/uacce/uacce.c
@@ -433,6 +433,20 @@ static ssize_t isolate_strategy_store(struct device *dev, struct device_attribut
return count;
}
+static ssize_t dev_usage_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct uacce_device *uacce = to_uacce_device(dev);
+ int ret;
+
+ ret = uacce->ops->get_dev_usage(uacce, buf, PAGE_SIZE - 1);
PAGE_SIZE, and you don't have to do:
+ if (ret < 0)That type of thing :(
+ return ret;
+
+ buf[ret++] = '\n';
Also, you got your math wrong above :(
upfront. Here get_dev_usage is a driver callback that dynamically
generates content -- the format is not known to the framework, so
there is no format string to emit. Having the callback write into a
temporary buffer and then sysfs_emit(buf, "%s", tmp) in the show
function would just add an unnecessary copy without gaining the
overflow protection that sysfs_emit normally provides.
way, don't have random formats for the same filename depending on random
hardware types. Use different sysfs files if you want to do that.
And this is just going to be a single value, nothing complex, so why do
you need a callback for that?
-- e.g. the HiSilicon ZIP device has separate compression and
decompression engines whose usage rates are independent and cannot
be aggregated into one meaningful number.
file".
Following your suggestion of different sysfs files, one approach isI don't know, just don't violate the one-version-per-file rule AND
to expose one file per algorithm. Each file contains a single int
(0-100) formatted with sysfs_emit(), and the callback returns int.
But the number of algorithms is driver-specific (1 to 3 in the
HiSilicon drivers), so the framework would need to create attributes
dynamically at registration time, which adds complexity.
I'm not sure this is the best approach. Do you have a better
suggestion for handling this case?
always have the same type of data in the file with the same name (i.e.
don't have a file that can contain different types of data.)
This propose api seems to violate all of that, so I wouldn't recommend
it at all.
Why is this info needed in userspace at all? What is userspace going to
do with it?
Userspace schedulers use this to decide whether to submit a task to
the hardware accelerator or fall back to CPU computation. When a
process initializes, it reads the device usage and compares it
against a threshold: if the accelerator is busy, the process uses
CPU computation for its lifetime; if it's idle, the process
submits tasks to the accelerator. This needs a stable,
programmatically readable interface.
The per-algorithm detail is necessary because a device may have
independent engines -- e.g. the HiSilicon ZIP device has separate
compression and decompression engines, and a process doing
compression should only check the compression usage, not the
decompression usage. Aggregating them into one value would cause
wrong scheduling decisions.
To follow the one-value-per-file rule, I propose exposing one sysfs
file per algorithm, with the algorithm name in the filename:
/sys/class/uacce/<dev>/dev_usage_compress
/sys/class/uacce/<dev>/dev_usage_decompress
Each file contains a single integer (0-100) formatted with
sysfs_emit(). The filenames are driver-defined based on the
algorithms the device supports, but every dev_usage_* file always
returns the same type -- a single usage percentage. Userspace
discovers the available files by listing the device directory.
Is this approach acceptable?
Thanks!
Weili
thanks,
greg k-h
.