[RFC] [Maverick] Enable CONFIG_TASK_DELAY_ACCT=y

[Tim Gardner]

On 06/21/2010 11:22 AM, Leann Ogasawara wrote:
> 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
>
>

Lets turn it on for Maverick. We've some lemmings out in front, e.g., 
"All other major Linux distributions are doing it..." :)

Actually, I was messing with this feature independently this morning. I 
think our initial performance impact assumptions were a bit pessimistic. 
If it proves to be of sufficient use, then I'll likely sponsor an SRU 
for Lucid as well (after a suitable amount of testing).

rtg
-- 
Tim Gardner tim.gardner at canonical.com