Re: [PATCH RFC 5.13 1/2] io_uring: add support for ns granularity of io_sq_thread_idle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



在 2021/4/29 下午5:11, Pavel Begunkov 写道:
On 4/29/21 4:41 AM, Hao Xu wrote:
在 2021/4/28 下午10:16, Jens Axboe 写道:
On 4/28/21 8:07 AM, Pavel Begunkov wrote:
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index e1ae46683301..311532ff6ce3 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -98,6 +98,7 @@ enum {
   #define IORING_SETUP_CLAMP    (1U << 4)    /* clamp SQ/CQ ring sizes */
   #define IORING_SETUP_ATTACH_WQ    (1U << 5)    /* attach to existing wq */
   #define IORING_SETUP_R_DISABLED    (1U << 6)    /* start with ring disabled */
+#define IORING_SETUP_IDLE_NS    (1U << 7)    /* unit of thread_idle is nano second */
     enum {
       IORING_OP_NOP,
@@ -259,7 +260,7 @@ struct io_uring_params {
       __u32 cq_entries;
       __u32 flags;
       __u32 sq_thread_cpu;
-    __u32 sq_thread_idle;
+    __u64 sq_thread_idle;

breaks userspace API

And I don't think we need to. If you're using IDLE_NS, then the value
should by definition be small enough that it'd fit in 32-bits. If you
I make it u64 since I thought users may want a full flexibility to set
idle in nanosecond granularity(eg. (1e6 + 10) ns cannot be set by

It's a really weird user requiring such a precision. u32 allows up to
~1s, and if more is needed users can switch to ms mode, so in the worst
case the precision is 1/1000 of the desired value, more than enough.

millisecond granularity). But I'm not sure if this deserve changing the
userspace API.
That's not about deserve or not, we can't break ABI. Can be worked around,
Is it for compatibility reason?
e.g. by taking resv fields, but don't see a reason

need higher timeouts, don't set it and it's in usec instead.

So I'd just leave this one alone.







[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux