CONFIG_TASK_DELAY_ACCT not enabled in kernel

[Brian Parma]

It seems the kernel is not compiled with CONFIG_TASK_DELAY_ACCT. This and CONFIG_TASK_IO_ACCOUNTING are required for iotop functionality (according to man iotop). This functionality is present in 9.10 but not in 10.04.

I'm testing on Xubuntu 10.04, but this is a kernel option so I'm guessing it affects all the distros.

uname -a : Linux isis 2.6.32-14-generic #20-Ubuntu SMP Sat Feb 20 05:38:50 UTC 2010 i686 GNU/Linux

[Charlie Kravetz (cjkgeek)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in linux.

When reporting bugs in the future please use apport, either via the appropriate application's "Help -> Report a Problem" menu or using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[James Troup (elmo)]

I'm seeing this in current lucid kernel (2.6.32-16-generic); removing the kernel-series-unknown tag and adding regression-potential tag as this makes iotop useless in lucid and it worked in karmic

[PresuntoRJ (fabio-tleitao)]

if you try running it, you get the following message:

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

[Mikael Gerdin (mgerdin)]

This bug looks like a duplicate of #493156 which has been marked as Wontfix
 and links to an email on the ubuntu kernel mailing-list:
https://lists.ubuntu.com/archives/kernel-team/2009-December/008029.html

[Christian Kujau (christiank)]

In the URL above it's mentioned that it would cause a performance hit and has therefore been disabled in the config. However, delay accounting can be disabled by passing nodelayacct as a boot parameter (see Documentation/accounting/delay-accounting.tx). I have not seen actual numbers confirming this performance hit - and I'd like to have TASK_DELAY_ACCT, so that things like iotop (a helpful tool that actually *helps* tracking I/O performance issues!) are useful again.

[Christian Kujau (christiank)]

I did a really quick test: bonnie++ [0] on a SunV40z, 16GB RAM with CONFIG_TASK_DELAY_ACCT=y and another test with nodelayacct: http://nerdbynature.de/bits/LP-532490/

AFAICT bonnie++ was slightly faster with nodelayacct for ext4, but slightly slower for btrfs. Latencies seem to be slightly lower (good!) for nodelayacct, but not always. I could not really find out a winner here. Maybe if you squint in the right way one may see something else. Given that, I still think that TASK_DELAY_ACCT=y is really important to have. Just look around: every time "disk I/O + Linux + performance" comes up, one is advised to use iotop. It'd good if Ubuntu would provide the envrionment for such analysis.

Thanks,
Christian.

[0] Yeah, I know. If anyone has an actual usecase where the performance hit for TASK_DELAY_ACCT=y vs. TASK_DELAY_ACCT=n can be seen, please let me know!

[Christian Kujau (christiank)]

Oh, and openSuSE 11.3, Fedora 13 and Debian's 2.6.32 kernel package have it enabled too:

CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

Dunno about Vista, though :-)

[tuxlover (propstmatthias)]

I was wondering if it is save to renable TASK_DELAY_ACCT=y in kernel source and recompile and install a new kernel image
in grub.