CONFIG_TASK_DELAY_ACCT error in “iotop” kernel 5.14

[ManuLinares]

ref: https://forum.manjaro.org/t/config-task-delay-acct-error-in-iotop-kernel-5-14/84466

kernel config: https://gitlab.manjaro.org/packages/core/linux514/-/blob/master/config#L141
CONFIG_TASK_DELAY_ACCT=y

Using kernel 5.14.7-2-MANJARO
iotop shows an error

CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %

now showing SWAPIN column but flag is enabled.

[bbonev]

I can't easily test that (no manjaro install around). I checked how it goes on a fresh arch install:

# uname -a
Linux arch-build 5.14.8-arch1-1 #1 SMP PREEMPT Sun, 26 Sep 2021 19:36:15 +0000 x86_64 GNU/Linux
# zgrep CONFIG_TASK_DELAY_ACCT /proc/config.gz 
CONFIG_TASK_DELAY_ACCT=y

And iotop runs fine.

Are you running iotop as root? (try as root, if not)
Do you have custom selinux rules? (try to disable selinux)

It is also possible that there is a problem in 5.14.7 that got fixed in 5.14.8; or there is a manjaro specific change that is not in arch. Can you install a more recent kernel?

Please update here as you find more info.

[ManuLinares]

Are you running iotop as root? (try as root, if not) Do you have custom selinux rules? (try to disable selinux)

I'm running as root. No selinux.

It is also possible that there is a problem in 5.14.7 that got fixed in 5.14.8; or there is a manjaro specific change that is not in arch. Can you install a more recent kernel?

I've just tried kernel 5.14.8, same error.

PS: kernel 5.13 is working fine without that message

[bbonev]

Which version of iotop do you run? Did you try to build from source (git)?

From the error message above, it looks like you are running the python version, which is different from this one (normally packaged as iotop-c)...

[ManuLinares]

You are right, I'm using python version.

I'm sorry, I think this is the repo https://repo.or.cz/w/iotop.git

[omgold]

I see the same issue with Arch.

Kernel is 5.14.8-arch1-1
iotop (Python) 0.6-8 behaves as above
iotop-c 1.19 shows the correct totals in the header, but the IO for individual processes are all zero.

[ManuLinares]

Oh yeah, the two columns that doesn't work on iotop-c are SWAPIN and IO.

[bbonev]

Confirmed, you can re-enable that by:

echo 1 > /proc/sys/kernel/task_delayacct

About SWAPIN - I have very thoroughly verified that the value coming from the kernel is displayed, but on all machines I have seen it is always 0 (maybe because I do not use swap?)

I am all ears for how to proceed with that - e.g. enable on start and restore on exit or some other strategy involving dialog with the user?

[pabs3]

@ManuLinares thanks for reporting this, btw I suggest using iotop-c as it is has more features and is maintained more than the iotop Python version, which is in maintenance mode.

@bbonev Since this is a sysctl and it affects performance of the host machine, and the sysadmin might turn it on or off while iotop is running and the sysadmin should generally be in control of sysctls (either via the sysctl command or via sysctl configuration files), so I think I would document the issue in the user interface and the documentation. I've updated the requirements docs and user-interface for iotop-py.

I expect you are right about SWAPIN being zero because you don't use swap. BTW it is zero most of the time anyway, unless your processes are swapped out and then start wanting to run and start swapping back into RAM.

[pabs3]

BTW, since this is a sysctl and can be changed at runtime, the mechanism to handle the values not being available should also handle the values both going away and coming back. Not sure if I'll find time to fix iotop-py for that, patches welcome though.

[bbonev]

I decided to keep the control of the sysctl manual; my changes are here: https://github.com/bbonev/iotop can you test and report if there are problems with that? After I gather some feedback it feels like a big enough change to release next version

[ManuLinares]

I expect you are right about SWAPIN being zero because you don't use swap. BTW it is zero most of the time anyway, unless your processes are swapped out and then start wanting to run and start swapping back into RAM.

I can confirm I am using swap. (Using the latest version from https://repo.or.cz/iotop.git with the changes)

swapUsage() {
  for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
}

Also, the column IO is showing always ZERO, as is SWAPIN. And the SWAPIN column when task_delayacct is deactivated, the message overlaps the IO column. But if it is in maintenance mode, so no worries I guess?

---

iotop-c

I decided to keep the control of the sysctl manual; my changes are here: https://github.com/bbonev/iotop can you test and report if there are problems with that? After I gather some feedback it feels like a big enough change to release next version

I've just compiled and tested it. The CTRL+t popup works fine but still SWAPIN column is ZERO all the way.
I disabled zswap, I've put vm.swappiness to 100, and used a shit ton of ram. swap is in usage.

EDIT: I saw a 0.01% showing up, but I think I have to specify, I am using --accumulated, I thought it would show accumulated swap usage but it doesn't. I guess it a missing feature, not a bug.
I think with the above Its working

[bbonev]

EDIT: I saw a 0.01% showing up, but I think I have to specify, I am using --accumulated, I thought it would show accumulated swap usage but it doesn't. I guess it a missing feature, not a bug. I think with the above Its working

Yes, that is not done. This value is in %, can you propose how to aggregate in accumulated mode? Maybe max, because avg does not seem useful in this case...

[ManuLinares]

As I see it there are two ways of doing it when selecting "-a" accumulated

1. The realtime accumulated: Per process adding swap in realtime.
2. The totals: Similar to the function in my example above, just show the total swap by process.

1 is not very useful, maybe to see what the kernel decides has to swap but IO should be more helpful.
2 is VERY useful, as seeing which process is consuming the most could be a helpful indicator

I have no other opinion at the moment. 🤷 ¯_(ツ)_/¯

[pabs3]

It looks like if you have ever turned on the kernel.task_delayacct sysctl for the current Linux boot, then the heuristic that iotop-py uses to find out if swapin/io are available, gives a false negative, since the Linux kernel still has some stats for the current boot. So I guess I will need to add detection of the sysctl as well. @bbonev Writing to the /proc file is equivalent to the sysctl command, they do the exact same thing, you can confirm that with strace. So you don't need to document both options. I suggest dropping mention of writing to the file though, since the sysctl option is shorter and more useful since writing the file when using sudo needs a subshell. PS: @bbonev don't add workarounds for false positives in static analysis tools, instead try to reduce them to a minimal test case using cvise or creduce and then file bugs upstream about the issue.

…

-- bye, pabs https://bonedaddy.net/pabs3/

[bbonev]

Thanks for reporting and all the feedback!
I am closing the issue - v1.20 fixes this.

@ManuLinares please open a separate issue about aggregating the IO and SWAPIN values.