Re: [PATCH v2] io_uring: add IORING_ENTER_NO_IOWAIT to not set in_iowait

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

 



Hi, David,

David Wei <dw@xxxxxxxxxxx> writes:

> io_uring sets current->in_iowait when waiting for completions, which
> achieves two things:
>
> 1. Proper accounting of the time as iowait time
> 2. Enable cpufreq optimisations, setting SCHED_CPUFREQ_IOWAIT on the rq
>
> For block IO this makes sense as high iowait can be indicative of
> issues.

It also let's you know that the system isn't truly idle.  IOW, it would
be doing some work if it didn't have to wait for I/O.  This was the
reason the metric was added (admins being confused about why their
system was showing up idle).

> But for network IO especially recv, the recv side does not control
> when the completions happen.
>
> Some user tooling attributes iowait time as CPU utilisation i.e. not

What user tooling are you talking about?  If it shows iowait as busy
time, the tooling is broken.  Please see my last mail on the subject:
  https://lore.kernel.org/io-uring/x49cz0hxdfa.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

> idle, so high iowait time looks like high CPU util even though the task
> is not scheduled and the CPU is free to run other tasks. When doing
> network IO with e.g. the batch completion feature, the CPU may appear to
> have high utilisation.

Again, iowait is idle time.

> This patchset adds a IOURING_ENTER_NO_IOWAIT flag that can be set on
> enter. If set, then current->in_iowait is not set. By default this flag
> is not set to maintain existing behaviour i.e. in_iowait is always set.
> This is to prevent waiting for completions being accounted as CPU
> utilisation.
>
> Not setting in_iowait does mean that we also lose cpufreq optimisations
> above because in_iowait semantics couples 1 and 2 together. Eventually
> we will untangle the two so the optimisations can be enabled
> independently of the accounting.
>
> IORING_FEAT_IOWAIT_TOGGLE is returned in io_uring_create() to indicate
> support. This will be used by liburing to check for this feature.

If I receive a problem report where iowait time isn't accurate, I now
have to somehow figure out if an application is setting this flag.  This
sounds like a support headache, and I do wonder what the benefit is.

[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