[RFC] [Maverick] Enable CONFIG_TASK_DELAY_ACCT=y
Leann Ogasawara
leann.ogasawara at canonical.com
Mon Jun 21 17:22:40 UTC 2010
Hi All,
The request to enable CONFIG_TASK_DELAY_ACCT has once again come up per
a request from the IS team (I'ved CC'd elmo). They could really use the
ability to use iotop to diagnose performance problems on our servers,
and they noted that other distributions have this option enabled. The
option is described as follows:
config TASK_DELAY_ACCT
bool "Enable per-task delay accounting (EXPERIMENTAL)"
depends on TASKSTATS
help
Collect information on time spent by a task waiting for system
resources like cpu, synchronous block I/O completion and swapping
in pages. Such statistics can help in setting a task's priorities
relative to other tasks for cpu, io, rss limits etc.
Say N if unsure.
Bug 493156 [1] captured the original request which we had marked as
Won't Fix based on the following:
https://lists.ubuntu.com/archives/kernel-team/2009-December/008029.html
Tim wrote, "I think I just stirred the mud on this one. I've been
chatting with Andy after he pointed out that this causes a performance
hit. Its been around since 2.6.18 and we've not enabled it for any other
release. Its used for intra-task prioritization. I only noticed it
because iotop was complaining, which in retrospect, is an insufficient
reason. IMHO it should remain disabled."
However, there have been quite a bit of rebuttals to this decision. In
particular the upstream developer Balbir Singh notes in comment 9 of bug
493156 [2], "Can someone help characterize the performance hit with
'perf' data or oprofile data using a standard benchmark? When we
developed the feature we ran a large set of benchmarks to ensure there
is no visible performance hit. If there is a hit or a side-effect, I
would be interested in fixing it upstream so that we can enable this
feature in Ubuntu."
Additionally, Christian Kujau, notes the following in comment 4 of bug
493156 [3],
"- Iotop doesn't work properly w/o CONFIG_TASK_DELAY_ACCT
- There is no measurable overhead when enabled. I tried to measure in
#532490, comment #6, but no winner there.
@Tim/Andy: please elaborate on the 'performance hit' with this option
enabled, I'm really curious if this is still valid for current kernels
and which usecase has been tested to determine this hit.
- The 'nodelayacct' can be used to disable delay accounting for those
usecases where an actual performance hit can be seen.
- All other major Linux distributions are doing it, only Ubuntu stands
out :-\"
I'd be inclined to turn this on especially given the fact that you can
disable it via the 'nodelayacct' kernel param. However, I would like to
know where we saw the original performance hit and how it was
measured/tested to see if I could reproduce before enabling it.
Thoughts?
Thanks,
Leann
[1] https://bugs.edge.launchpad.net/ubuntu/+bug/493156
[2] https://bugs.edge.launchpad.net/ubuntu/+bug/493156/comments/9
[3] https://bugs.edge.launchpad.net/ubuntu/+bug/493156/comments/4
More information about the kernel-team
mailing list