FS#10533 - latencytop support in 2.6.25 arch's stock kernel

Attached to Project: Arch Linux
Opened by João Rodrigues (gothicknight) - Thursday, 29 May 2008, 15:03 GMT
Last edited by Greg (dolby) - Tuesday, 17 June 2008, 10:44 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Very Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
It's possible to compile the kernel with CONFIG_LATENCYTOP set?
This is needed for use with latencytop.

Additional info:
* package version(s)
> kernel26 2.6.25-4
> latencytop 0.4-1 (AUR)
* config and/or log files etc.
> N/A

Steps to reproduce:
> Try running latencytop app. It should exit with message "Please enable the CONFIG_LATENCYTOP configuration in your kernel.\n Exiting.."
This task depends upon

Closed by  Greg (dolby)
Tuesday, 17 June 2008, 10:44 GMT
Reason for closing:  Won't implement
Comment by Aaron Griffin (phrakture) - Thursday, 29 May 2008, 16:54 GMT
Does this have any negative impact?
Comment by Thomas Bächler (brain0) - Thursday, 29 May 2008, 17:21 GMT
I think it has. This was requested when 2.6.25 was still in testing and I decided against it, but cannot remember why. I think latencytop increases latency (which is kind of ironic).
Comment by Aaron Griffin (phrakture) - Thursday, 29 May 2008, 17:24 GMT
Well I certainly don't want *my* kernel slower because someone wants to run latencytop, and I'm sure other users feel similar. I recommend closing with a "won't implement"
Comment by Thomas Bächler (brain0) - Thursday, 29 May 2008, 17:33 GMT
I was planning to do that, but first I need to do some research to confirm that.
Comment by Jan de Groot (JGC) - Friday, 30 May 2008, 09:33 GMT
Debian also closed this as won't implement. Enabling CONFIG_LATENCYTOP enables loads of debugging options and slows down or enlarges the kernel.

Edit: I see a lot of feature requests for debug stuff these days. Wasn't our policy to strip debug symbols from binaries? Why is this different for kernels?
Comment by João Rodrigues (gothicknight) - Friday, 30 May 2008, 13:59 GMT
Very well, if this has indeed slowdowns in kernel I'm also against this be considered. This was only a very low feature request for testing that could be of use by others, nothing else.

Just a remark, we have, CONFIG_HAVE_LATENCYTOP_SUPPORT=y in stock arch. If we don't have latencytop support than this might be pointless.
On thought is, in the long run, a kernel26-debug for testing only could come in handy to test arch's latencies.

Regarding the debug symbols, aren't they possible to be done in makepkg's CFLAGS using packages PKGBUILD?
Comment by Dan McGee (toofishes) - Friday, 30 May 2008, 22:01 GMT
I thought tpowa enabled this at one point, it caused problems, and then disabled it. Perhaps take a look at the CVS history?

Regardless I'd say won't implement- our kernel isn't meant to be a debugging playground, it is meant to be usable out of the box. It is not too hard for someone to compile their own if need be for latencytop support, or for someone to add a PKGBUILD to AUR doing this.

Regarding CONFIG_HAVE_LATENCYTOP_SUPPORT=y, that just means the arch you are building for supports latencytop, not that anything is enabled. So that is always there.

Loading...