Ubuntu

Please enable CONFIG_TASK_DELAY_ACCT

Reported by Hernando Torque on 2009-12-06
398
This bug affects 93 people
Affects Status Importance Assigned to Milestone
iotop (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned
Natty
Undecided
Unassigned
linux (Ubuntu)
Medium
Leann Ogasawara
Lucid
Undecided
Tim Gardner
Maverick
Undecided
Unassigned
Natty
Medium
Leann Ogasawara

Bug Description

iotop 0.3.2-1 needs CONFIG_TASK_DELAY_ACCT enabled, and currently (2.6.32-7.9) only shows:

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

Please consider enabling this option.

Andy Whitcroft (apw) on 2009-12-07
tags: added: kernel-series-unknown
Andy Whitcroft (apw) on 2009-12-09
tags: added: lucid
removed: kernel-series-unknown
Changed in linux (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist

Hi Hernando,

It seems discussion regarding this specific config option took place on the kernel-team mailing list and it was decided to not enable this option. Please re-raise the discussion on the kernel-team mailing list if you'd like to pursue this further. Thanks.

https://lists.ubuntu.com/archives/kernel-team/2009-December/008029.html

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
Hernando Torque (htorque) wrote :

Thanks for the link!

With this information "Won't Fix" seems reasonable. :-)

pdf (pdffs) wrote :

Considering this has been raised 4 separate times (besides bringing into question people's searching skills), suggests this issue ought to be re-examined.

If necessary, the accounting can be disabled by default as per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532490/comments/5 so as to have no impact, except when explicitly enabled, which would allow a common and valuable tool for administrators to be used as intended.

Christian Kujau (christiank) wrote :

Wow. I just came over from #532490 to see that bugs like these ("wishlist", really?) are being "happily" set to WONTFIX. I still fail to understand the reasoning behind that decision and I hope this will be revisited. Again:

- 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 :-\

scott (sahendrickson) wrote :

Can this bug please be reopened until the underlying problem (i.e., that iotop does not work) is addressed? Simply stating that something is not optimal does not address the functionality that is missing as a result.

damaan (jon-ekdahl) wrote :

Please reconsider enabling CONFIG_TASK_DELAY_ACCT. Just because there is a slight penalty in some use cases doesn't motivate disabling it, when iotop and possibly other valuable tools are not working as they should. People that really need those extra milliseconds are usually better equipped when it comes to messing with kernel variables anyway, so why not keep it enabled by default and let them disable it.

At least provide some numbers for the actual penalty, preferrably with a test case attached, to motivate the decision. Just stating that CONFIG_TASK_DELAY_ACCT "causes a performance hit" is not good enough.

pdf (pdffs) wrote :

And really, you're going to force me to join a mailing list I have no other interest in (and get flooded with the associated emails that are of no interest to me), to lobby this issue that is clearly a bug, rather than have it dealt with via the nominated means for users to report and have bugs actioned? Surely, that's a ridiculous request.

I subscribed you Leann, since you will not have seen the numerous replies on this bug or it's duplicates since you closed the issue. Please take a second to read all the bugs and re-evaluate your position.

hackel (hackel) wrote :

If it is possible for programs like iotop to enable this feature only when they are using it, then I would very much like to see this added. Otherwise no, if it is going to cause a performance hit. Admins can easily roll their own custom kernel if necessary.

Balbir Singh (bsingharora) wrote :

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.

Wes Turner (wes-turner) wrote :

+1 on enabling CONFIG_TASK_DELAY_ACCT by default.

pdf (pdffs) wrote :

Since all we have to reference as far as the purported performance hit is Tim Gardner's post to the mailing list about a conversation where "Andy" suggested there was a hit, yet we have upstream (thanks Balbir) saying there should be no hit, I'd suggest that either Tim or his source for this information need to tell us what precise methodology was used to determine that there is an impact, or this bug needs to be resolved by enabling the option.

At the very least, someone with appropriate privileges should remove the Won't Fix so that this bug can get some useful attention.

tags: removed: lucid

I re-opened this for discussion on the kernel-team mailing list:

https://lists.ubuntu.com/archives/kernel-team/2010-June/011238.html

The end result is that we'll enable this in Maverick. I'll try and get a kernel uploaded today with this change. And as Tim notes in the mailnig list thread, "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)." Thanks.

Changed in linux (Ubuntu):
assignee: nobody → Leann Ogasawara (leannogasawara)
importance: Wishlist → Medium
milestone: none → maverick-alpha-2
status: Won't Fix → In Progress

Thanks!

--
Wes Turner

On Mon, Jun 21, 2010 at 1:22 PM, Leann Ogasawara <
<email address hidden>> wrote:

> I re-opened this for discussion on the kernel-team mailing list:
>
> https://lists.ubuntu.com/archives/kernel-team/2010-June/011238.html
>
> The end result is that we'll enable this in Maverick. I'll try and get a
> kernel uploaded today with this change. And as Tim notes in the mailnig
> list thread, "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)." Thanks.
>
> ** Changed in: linux (Ubuntu)
> Importance: Wishlist => Medium
>
> ** Changed in: linux (Ubuntu)
> Status: Won't Fix => In Progress
>
> ** Changed in: linux (Ubuntu)
> Milestone: None => maverick-alpha-2
>
> ** Changed in: linux (Ubuntu)
> Assignee: (unassigned) => Leann Ogasawara (leannogasawara)
>
> --
> Please enable CONFIG_TASK_DELAY_ACCT
> https://bugs.launchpad.net/bugs/493156
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “iotop” package in Ubuntu: New
> Status in “linux” package in Ubuntu: In Progress
>
> Bug description:
> iotop 0.3.2-1 needs CONFIG_TASK_DELAY_ACCT enabled, and currently
> (2.6.32-7.9) only shows:
>
> > CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and
> IO %
>
> Please consider enabling this option.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/iotop/+bug/493156/+subscribe
>

It was I who contacted Balbir Singh (which subsequently commented
here), Tim Gardner notes on the mailing list:

    "Actually, I was messing with this feature independently this morning. I
    think our initial performance impact assumptions were a bit pessimistic."

Does that mean that there never was a performance impact as initially
suggested, it was just assumed to exist. I.e. this was always a
non-issue.

I'm not looking for someone to blame, just wondering if this needs to
be followed up with upstream. And whether running a kernel with
CONFIG_TASK_DELAY_ACCT=y and without nodelayacct actually has a
performance impact that users of Ubuntu might be concerned about in
some odd cases.

Thanks.

1. https://lists.ubuntu.com/archives/kernel-team/2010-June/011240.html

PresuntoRJ (fabio-tleitao) wrote :

Thanx :)

2010/6/21 Ævar Arnfjörð Bjarmason <email address hidden>

> It was I who contacted Balbir Singh (which subsequently commented
> here), Tim Gardner notes on the mailing list:
>
> "Actually, I was messing with this feature independently this morning. I
> think our initial performance impact assumptions were a bit
> pessimistic."
>
> Does that mean that there never was a performance impact as initially
> suggested, it was just assumed to exist. I.e. this was always a
> non-issue.
>
> I'm not looking for someone to blame, just wondering if this needs to
> be followed up with upstream. And whether running a kernel with
> CONFIG_TASK_DELAY_ACCT=y and without nodelayacct actually has a
> performance impact that users of Ubuntu might be concerned about in
> some odd cases.
>
> Thanks.
>
> 1. https://lists.ubuntu.com/archives/kernel-team/2010-June/011240.html
>
> --
> Please enable CONFIG_TASK_DELAY_ACCT
> https://bugs.launchpad.net/bugs/493156
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Fábio Leitão
..-. .- -... .. --- .-.. . .. - .- --- ...-.-

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.35-5.6

---------------
linux (2.6.35-5.6) maverick; urgency=low

  [ Amit Kucheria ]

  * [Config] update omap flavour description

  [ Andy Whitcroft ]

  * update to ubuntu-debian:508b7aa34b578c0d1e51bfb571f2bfb824dc65ac
    - LP: #570500, #576274
  * SAUCE: add option to hand off all kernel parameters to init
    - LP: #586386
  * [Config] enable passing all kernel command line to init
    - LP: #586386
  * [Config] disable CONFIG_VMI
    - LP: #537601
  * [Config] enable CONFIG_IPV6_SIT_6RD
    - LP: #591869
  * [Config] enable CONFIG_VMWARE_BALOON as module
    - LP: #592039

  [ Leann Ogasawara ]

  * Revert "SAUCE: pm: Config option to disable handling of console during
    suspend/resume"
    - LP: #594885
  * [Config] Remove CONFIG_PM_DISABLE_CONSOLE
  * [Config] ports: enable passing all kernel command line to init
    - LP: #586386
  * [Config] Enable CONFIG_FB_VESA=y for x86
  * [Config] Add CONFIG_FRAMEBUFFER_CONSOLE=y to config enforcer
  * [Config] Add CONFIG_FB_VESA=y for x86 to config enforcer
  * [Config] Enable CONFIG_TASK_DELAY_ACCT=y
    - LP: #493156

  [ Mathieu Poirier ]

  * ARM: Adding MosChip MCS7830 to nic-usb
    - LP: #584920

  [ Upstream Kernel Changes ]

  * Revert "[Upstream] docbook: need xmldoclinks for all doc types"
  * docbook: need xmldoclinks for all doc types
  * perf probe: Add kernel source path option
 -- Leann Ogasawara <email address hidden> Thu, 17 Jun 2010 08:05:29 -0700

Changed in linux (Ubuntu):
status: In Progress → Fix Released
Uqbar (uqbar) wrote :

The bug it's not fixed. It will as soon as Maverick will be released.
So, please, backport the fix to the current LTS release wich happens to be Lucid.

Paul Elliott (omahn) wrote :

Please can a SRU be initiated to enable CONFIG_TASK_DELAY_ACCT in Lucid given the LTS nature of Lucid. It's extremely useful to have full statistics in iotop and in our server testing having this option enabled has no noticeable performance hit.

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - Maverick Meerkat.

This is a significant bug in Ubuntu. If you need a fix for the bug in previous versions of Ubuntu, please do steps 1 and 2 of the SRU Procedure [1] to bring the need to a developer's attention.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Paul Elliott (omahn) wrote :

SRU justification

IMPACT: Without this option enabled tools such as iotop are missing functionality that is extremely useful for diagnosing performance issues.

DEVELOPMENT BRANCH: The option CONFIG_TASK_DELAY_ACCT was enabled in Mavericks kernel 2.6.35-5.6 without any reported regressions.

PATCH: Simply enable CONFIG_TASK_DELAY_ACCT in next kernel release.

TEST CASE: Run iotop and check that SWAPIN and IO columns are populated.

REGRESSION POTENTIAL: Old reports exist of performance regressions with the option enabled, however these regressions have never been proven or quantified to the best of my knowledge and has never been witnessed at our site running kernels with the option enabled.

tags: added: lucid maverick
removed: iotop
Changed in iotop (Ubuntu):
status: New → Fix Released
Sorin Stoiana (sstoiana) wrote :

Subscribed ubuntu-sru. Hoping to see this fixed in Lucid as well.

Martin Pitt (pitti) wrote :

Kernel team, do you agree with the regression potential described in comment 20? If this imposes a performance degradation, it's not appropriate for an SRU.

Uqbar (uqbar) wrote :

In that case, what would be iotop for?

pdf (pdffs) wrote :

On 22/09/10 17:36, Martin Pitt wrote:
> Kernel team, do you agree with the regression potential described in
> comment 20? If this imposes a performance degradation, it's not
> appropriate for an SRU.
>

You mean, does the kernel team agree that (paraphrasing), "There were
some unsubstantiated claims on the Ubuntu Kernel mailing list that this
option would incur a performance penalty, however all empirical tests,
and responses from upstream kernel developers, refute these claims."?

Because that's the scenario.

Uqbar (uqbar) wrote :

Well, if we read the current status there's a "fix released". Which means "yeas, we can!" or "Yeas, maybe we will, somewhere in the future".

Martin Pitt (pitti) on 2011-01-03
Changed in iotop (Ubuntu Lucid):
status: New → Invalid
Changed in linux (Ubuntu Lucid):
status: New → Triaged
Tim Gardner (timg-tpi) wrote :

I've proposed a Lucid patch on <email address hidden> that will enable CONFIG_TASK_DELAY_ACCT whilst preserving the released functionality. You can enable delay accounting by adding 'delayacct' to the kernel boot command.

https://lists.ubuntu.com/archives/kernel-team/2011-January/013936.html

Changed in linux (Ubuntu Lucid):
assignee: nobody → Tim Gardner (timg-tpi)
status: Triaged → In Progress
Changed in linux (Ubuntu Maverick):
status: New → Fix Released
Changed in iotop (Ubuntu Maverick):
status: New → Invalid
Changed in iotop (Ubuntu Natty):
status: Fix Released → Invalid
Tim Gardner (timg-tpi) on 2011-01-03
Changed in linux (Ubuntu Natty):
milestone: maverick-alpha-2 → none
Tim Gardner (timg-tpi) on 2011-01-03
Changed in linux (Ubuntu Lucid):
status: In Progress → Fix Committed
Christian Kujau (christiank) wrote :

Tim, If I understand your comment correctly, you're going to enable CONFIG_TASK_DELAY_ACCT in the config but the actual delay accounting will be disabled unless booted with "delayacct"? What happened to Leann's RFC[0] and all the comments in this bug? Why introduce another bootoption for that? What was the reasoning here?

Also, I don't approve of your "lemming" comparision[1]: I merely mentioned that other distributions have enabled this feature and are apparently not reporting any downsides - I did not mention this to imply that we should blindly follow others.

Thanks,
Christian.

[0] https://lists.ubuntu.com/archives/kernel-team/2010-June/011238.html
[0] https://lists.ubuntu.com/archives/kernel-team/2010-June/011240.html

Alvin (alvind) wrote :

Is there any reason to preserve the released behaviour of Lucid? Are there situations where CONFIG_TASK_DELAY_ACCT has to be disabled?

Tim Gardner (timg-tpi) wrote :

According to SRU policy no new features can be added to a kernel without a feature exception. The other prime directive of the SRU policy is to add no regressions. Given the amount of code that this config option enables, I chose the path of least risk while still providing the ability for savvy users to enable task delay accounting.

So, yes, you will have to modify your grub boot command line. If using grub2, then I suggest adding it to /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT. Remember to run update-grub afterwards.

Accepted linux into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Richard Hansen (a7x) wrote :

I see the new kernel packages (2.6.32-28.55), but linux-image-generic still depends on linux-image-2.6.32-27-generic. Did someone forget to update the linux-meta package?

Steve Conklin (sconklin) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed' to 'verification-done'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

pdf (pdffs) wrote :

Verification done with 'delayacct' command line and linux-image-2.6.32-28-generic (2.6.32-28.55).

tags: added: verification-done
removed: verification-needed
Christian Kujau (christiank) wrote :

Here too: linux-image-2.6.32-28-generic (2.6.32-28.55) with 'delayacct' running fine, iotop working too. Thanks!

Launchpad Janitor (janitor) wrote :
Download full text (10.1 KiB)

This bug was fixed in the package linux - 2.6.32-28.55

---------------
linux (2.6.32-28.55) lucid-proposed; urgency=low

  * Another version bump because of abi check failure
  * Tracking Bug
    - LP: #699885

linux (2.6.32-28.54) lucid-proposed; urgency=low

  * Another version bump because of upload failure

linux (2.6.32-28.53) lucid-proposed; urgency=low

  * Another version bump because of upload failure

linux (2.6.32-28.52) lucid-proposed; urgency=low

  [ Steve Conklin ]

  * (removed old tracking bug link)

linux (2.6.32-28.51) lucid-proposed; urgency=low

  [ Steve Conklin ]

  * bumped version due to build fail

linux (2.6.32-28.50) lucid-proposed; urgency=low

  [ Tim Gardner ]

  * SAUCE: Change nodelayacct boot parameter polarity.
    - LP: #493156
  * [Config] CONFIG_TASK_DELAY_ACCT=y
    - LP: #493156

  [ Upstream Kernel Changes ]

  * ipc: initialize structure memory to zero for compat functions
  * tcp: Increase TCP_MAXSEG socket option minimum.
    - CVE-2010-4165
  * perf_events: Fix perf_counter_mmap() hook in mprotect()
    - CVE-2010-4169
  * af_unix: limit unix_tot_inflight
    - CVE-2010-4249
  * AppArmor: fix the upper bound check for the next/check table
    - LP: #581525
  * NFS: Fix panic after nfs_umount()
    - LP: #683938
  * block: Ensure physical block size is unsigned int
    - LP: #688669
  * block: limit vec count in bio_kmalloc() and bio_alloc_map_data()
    - LP: #688669
  * block: take care not to overflow when calculating total iov length
    - LP: #688669
  * block: check for proper length of iov entries in blk_rq_map_user_iov()
    - LP: #688669
  * jme: Fix PHY power-off error
    - LP: #688669
  * irda: Fix parameter extraction stack overflow
    - LP: #688669
  * irda: Fix heap memory corruption in iriap.c
    - LP: #688669
  * i2c-pca-platform: Change device name of request_irq
    - LP: #688669
  * microblaze: Fix build with make 3.82
    - LP: #688669
  * Staging: asus_oled: fix up some sysfs attribute permissions
    - LP: #688669
  * Staging: asus_oled: fix up my fixup for some sysfs attribute
    permissions
    - LP: #688669
  * Staging: line6: fix up some sysfs attribute permissions
    - LP: #688669
  * hpet: fix unwanted interrupt due to stale irq status bit
    - LP: #688669
  * hpet: unmap unused I/O space
    - LP: #688669
  * olpc_battery: Fix endian neutral breakage for s16 values
    - LP: #688669
  * percpu: fix list_head init bug in __percpu_counter_init()
    - LP: #688669
  * um: remove PAGE_SIZE alignment in linker script causing kernel
    segfault.
    - LP: #688669
  * um: fix global timer issue when using CONFIG_NO_HZ
    - LP: #688669
  * numa: fix slab_node(MPOL_BIND)
    - LP: #688669
  * hwmon: (lm85) Fix ADT7468 frequency table
    - LP: #688669
  * mm: fix return value of scan_lru_pages in memory unplug
    - LP: #688669
  * mm: fix is_mem_section_removable() page_order BUG_ON check
    - LP: #688669
  * ssb: b43-pci-bridge: Add new vendor for BCM4318
    - LP: #688669
  * sgi-xpc: XPC fails to discover partitions with all nasids above 128
    - LP: #688669
  * xen: ensure that all event channels start off bound to VCPU 0
    - LP: #688669
  * xen: don't bother to...

Changed in linux (Ubuntu Lucid):
status: Fix Committed → Fix Released
Lackhead (clake-lackhead) wrote :

I see that this has been fixed in the -generic kernel release; has there been any discussion about doing the same for the -server kernel?

Thank you!

In 10.04.2 linux-image-server depends on linux-image-generic-pae which in
turn depends on linux-image-2.6.32-21-generic-pae which has
TASK_DELAY_ACCT enabled.

However, be sure to pass "delayacct" to your boot options, otherwise it
won't work (sigh...)

Christian.

Nicholas Janssen (xnicholas) wrote :

All of you are idiots. To disable an extremely valuable diagnostic feature, because some idiot lies about a "performance hit"...

This kind of 'cut off thumb because it might slow typing down' blatant atrocity , because a moron complains about "performance hit", without proof or numbers! This cancerous thinking will destroy ubuntu, fast and permanently.

This issue is still broken:

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

2.6.32-41-generic-pae #88-Ubuntu SMP Thu Mar 29 14:24:36 UTC 2012 i686 GNU/Linux

cat /etc/issue
Ubuntu 10.04.4 LTS

Christian Kujau (christiank) wrote :

Whooha, language!

And I think they "fixed" it, albeit in a weird way: CONFIG_TASK_DELAY_ACCT is enabled in the kernel config, but the feature is still disabled unless the kernel is booted with "delayacct" as a boot parameter, see my comment above.

Balbir Singh (bsingharora) wrote :

On Thu, May 3, 2012 at 11:59 PM, Christian Kujau
<email address hidden> wrote:
> Whooha, language!
>
> And I think they "fixed" it, albeit in a weird way:
> CONFIG_TASK_DELAY_ACCT is enabled in the kernel config, but the feature
> is still disabled unless the kernel is booted with "delayacct" as a boot
> parameter, see my comment above.
>

I am not sure who made the decision and on what data, but
TASK_DELAY_ACCT should be the least of the problems when it comes to
overheads.

The correct path IMHO is to show us the overhead and lets fix it if it
is unacceptable

Balbir

SaveTheRbtz (savetherbtz) wrote :

On Fri, May 4, 2012 at 5:20 AM, Balbir Singh <email address hidden> wrote:
> On Thu, May 3, 2012 at 11:59 PM, Christian Kujau
> <email address hidden> wrote:
>> Whooha, language!
>>
>> And I think they "fixed" it, albeit in a weird way:
>> CONFIG_TASK_DELAY_ACCT is enabled in the kernel config, but the feature
>> is still disabled unless the kernel is booted with "delayacct" as a boot
>> parameter, see my comment above.
>>
>
> I am not sure who made the decision and on what data, but
> TASK_DELAY_ACCT should be the least of the problems when it comes to
> overheads.
>
> The correct path IMHO is to show us the overhead and lets fix it if it
> is unacceptable
>
Decision was totally right. One should NOT change behavior of kernel
in the middle of LTS lifecycle (e.g. like it was done to
CONFIG_NET_NS). Of cause it seems kinda strange that CONFIG_SCHEDSTATS
is set to "y" and we are talking about CONFIG_TASK_DELAY_ACCT
overhead.

And yes, at least some numbers would be nice (esp. form Nicholas
Janssen (xnicholas) who says that there is no overhead on his
workload).

Nicholas Janssen (xnicholas) wrote :

I have done a prelimiary test on harddrive speeds with delayacct disabled ( the new default after the atrocity of it being removed) and with it enabled...

The limted test script I created shows a clear winner:

on average delayacct is faster enabled.

I cannot explain this. I need someone else to verify the data.

attached is all my data, how to enable delayacct, and a copypaste of the bash script i used for testing... (use time to measure the exact time to user/system/)

Nicholas Janssen (xnicholas) wrote :

I await any reply to the evidence that i have posted that

"delayacct is faster enabled"

Barry Allard (steakknife) wrote :

Necromancing:

I'm not presently familiar with reputations of reporters, commenters or triagers in this particular instance.

However as a data-point, a popular enterprise server distro latest current as of writing (kernel-2.6.32-279.5.1.el6 amd64) enables 4 CONFIG_TASK kernel options mentioned elsewhere.
ᐅ grep .config CONFIG_TASK *
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

Although it's trivial to piece together a custom kernel repo, a good distro like Ubuntu Server LTS might want to stay consistent and reliable. This was the main differentiator against standardizing on use Ubuntu's upstream in our last infrastructure refresh. Can't say what the next cycle will be just yet though.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers