Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support
Am Mittwoch, 27. Juni 2012 schrieb Ben Hutchings: On Tue, 2012-06-26 at 12:46 +0200, Martin Steigerwald wrote: [...] The current Debian kernels all lack latencytop support: [...] Please consider activating this support again. What do you mean, 'again'? I thought this was once working out of the box, but maybe that was at a time where I compiled my own kernels and had it enabled. Otherwise someone who wants to use latencytop needs to recompile the kernel which greatly reduces the usefulness of the latencytop package. This costs 1680 or 3360 bytes of non-paged memory for every thread in the system (depending on word size), even if the feature is never actually used. On my laptop, for example, this would be about a megabyte. I really don't think this is a good idea. I found out that it will need the framepointer stuff which makes the kernel slightly larger and slower only after writing the bug report. While I do not care that much about the megabyte given current memory sizes, I am concerned about the slightly slower. And then its declared as kernel hacking feature in the configuration anyway. And for older / embedded machines 1 MiB might be much. So I can understand your reasoning. Feel free to close as won't fix or dependent / waiting for upstream fix if thats possible. It is probably possible to change the way the latency records are kept so that this memory is allocated only when needed, but I'm unlikely to find the time to do that. Care to elaborate on that one a bit. I am willing to open a upstream bug report about that and include your idea and a reference to this debian bug report. Thanks, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support
On Wed, 2012-06-27 at 10:34 +0200, Martin Steigerwald wrote: Am Mittwoch, 27. Juni 2012 schrieb Ben Hutchings: On Tue, 2012-06-26 at 12:46 +0200, Martin Steigerwald wrote: [...] The current Debian kernels all lack latencytop support: [...] Please consider activating this support again. What do you mean, 'again'? I thought this was once working out of the box, but maybe that was at a time where I compiled my own kernels and had it enabled. I think it must have been, as there is no record of this in the changelog. Otherwise someone who wants to use latencytop needs to recompile the kernel which greatly reduces the usefulness of the latencytop package. This costs 1680 or 3360 bytes of non-paged memory for every thread in the system (depending on word size), even if the feature is never actually used. On my laptop, for example, this would be about a megabyte. I really don't think this is a good idea. I found out that it will need the framepointer stuff which makes the kernel slightly larger and slower only after writing the bug report. I didn't even get as far as that, but yes. This would particularly hurt i386 which is short of registers. While I do not care that much about the megabyte given current memory sizes, I am concerned about the slightly slower. And then its declared as kernel hacking feature in the configuration anyway. And for older / embedded machines 1 MiB might be much. So I can understand your reasoning. Feel free to close as won't fix or dependent / waiting for upstream fix if thats possible. It is probably possible to change the way the latency records are kept so that this memory is allocated only when needed, but I'm unlikely to find the time to do that. Care to elaborate on that one a bit. I am willing to open a upstream bug report about that and include your idea and a reference to this debian bug report. The definition of struct task_struct includes: #ifdef CONFIG_LATENCYTOP int latency_record_count; struct latency_record latency_record[LT_SAVECOUNT]; #endif I was thinking that latency_record could be changed to a pointer, and the array allocated only when latency tracing is turned on. This should be easy to do for new tasks; harder if existing tasks should also be traced. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support
Package: linux-2.6 Version: 3.4.1-1~experimental.1 Severity: normal Dear Maintainer, On reporting latencytop: fails with error no protocol specified I found: http://bugs.debian.org/679091 I found: ms@mango:~ sux Passwort: xauth: file /root/.Xauthority does not exist bash: Kann die Prozessgruppe des Terminals nicht setzen (-1).: Unpassender IOCTL (I/O-Control) für das Gerät bash: Keine Job Steuerung in dieser Shell. mango:/home/ms# latencytop mount: none already mounted or /sys/kernel/debug/ busy mount: according to mtab, none is already mounted on /sys/kernel/debug Please enable the CONFIG_LATENCYTOP configuration in your kernel. Exiting... The current Debian kernels all lack latencytop support: mango:~# grep LATENCY /boot/config-* /boot/config-3.2.0-2-amd64:CONFIG_HAVE_LATENCYTOP_SUPPORT=y /boot/config-3.2.0-2-amd64:# CONFIG_LATENCYTOP is not set /boot/config-3.3.0-trunk-amd64:CONFIG_HAVE_LATENCYTOP_SUPPORT=y /boot/config-3.3.0-trunk-amd64:# CONFIG_LATENCYTOP is not set /boot/config-3.4-trunk-amd64:CONFIG_HAVE_LATENCYTOP_SUPPORT=y /boot/config-3.4-trunk-amd64:# CONFIG_LATENCYTOP is not set Please consider activating this support again. Otherwise someone who wants to use latencytop needs to recompile the kernel which greatly reduces the usefulness of the latencytop package. Thanks, Martin -- Package-specific info: ** Version: Linux version 3.4-trunk-amd64 (Debian 3.4.1-1~experimental.1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Wed Jun 6 10:34:53 CEST 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.4-trunk-amd64 root=UUID=459c3940-f915-460f-a673-386121d7a8c6 ro resume=/dev/sda7 no_console_suspend ** Tainted: WO (4608) * Taint on warning. * Out-of-tree module has been loaded. ** Kernel log: [ 8225.257334] e1000e :00:19.0: irq 40 for MSI/MSI-X [ 8225.257337] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X [ 8225.257376] ehci_hcd :00:1d.0: setting latency timer to 64 [ 8225.257389] usb usb2: root hub lost power or was reset [ 8225.257396] pci :00:1e.0: setting latency timer to 64 [ 8225.257413] ahci :00:1f.2: setting latency timer to 64 [ 8225.261287] ehci_hcd :00:1d.0: cache line size of 32 is not supported [ 8225.306523] parport_pc 00:0a: activated [ 8225.306774] serial 00:0b: activated [ 8225.577530] ata8: SATA link down (SStatus 0 SControl 300) [ 8225.577561] ata7: SATA link down (SStatus 0 SControl 300) [ 8225.577591] ata5: SATA link down (SStatus 0 SControl 300) [ 8225.613435] usb 1-1: reset high-speed USB device number 2 using ehci_hcd [ 8225.749017] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 8225.749107] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 8225.749137] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 8225.752692] ata4.00: configured for UDMA/100 [ 8225.755299] ata3.00: configured for UDMA/133 [ 8225.755417] sd 2:0:0:0: [sda] Starting disk [ 8225.757292] ata6.00: configured for UDMA/133 [ 8225.757367] sd 5:0:0:0: [sdb] Starting disk [ 8225.856806] usb 2-1: reset high-speed USB device number 2 using ehci_hcd [ 8226.060330] usb 1-1.4: reset high-speed USB device number 3 using ehci_hcd [ 8227.038062] usb 2-1.8: reset low-speed USB device number 4 using ehci_hcd [ 8227.576710] usb 2-1.7: reset low-speed USB device number 3 using ehci_hcd [ 8227.870701] PM: restore of devices complete after 2624.032 msecs [ 8227.870807] PM: Image restored successfully. [ 8227.870809] Restarting tasks ... done. [ 8227.873014] PM: Basic memory bitmaps freed [ 8228.008570] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx [ 8903.147658] scsi_verify_blk_ioctl: 444 callbacks suppressed [ 8903.147664] mdadm: sending ioctl 1261 to a partition! [ 8903.147668] mdadm: sending ioctl 1261 to a partition! [ 8903.294210] mdadm: sending ioctl 1261 to a partition! [ 8903.294217] mdadm: sending ioctl 1261 to a partition! [ 8903.385724] mdadm: sending ioctl 1261 to a partition! [ 8903.385728] mdadm: sending ioctl 1261 to a partition! [ 8903.489773] mdadm: sending ioctl 1261 to a partition! [ 8903.489780] mdadm: sending ioctl 1261 to a partition! [ 8903.649346] mdadm: sending ioctl 1261 to a partition! [ 8903.649350] mdadm: sending ioctl 1261 to a partition! [ 8908.319036] scsi_verify_blk_ioctl: 44 callbacks suppressed [ 8908.319039] mdadm: sending ioctl 1261 to a partition! [ 8908.319041] mdadm: sending ioctl 1261 to a partition! [ 8908.415940] mdadm: sending ioctl 1261 to a partition! [ 8908.415947] mdadm: sending ioctl 1261 to a partition! [ 8908.884496] JFS: nTxBlock = 8192, nTxLock = 65536 [ 8908.935072] NTFS driver 2.1.30 [Flags: R/W MODULE]. [ 8908.995222] QNX4 filesystem 0.2.3 registered. [ 8909.024033] fuse init (API version 7.18) [ 8910.918371] blockdev: sending ioctl 125d to a partition! [ 8910.918377] blockdev: sending ioctl 125d to a partition! [ 8910.931572] blockdev: sending ioctl 125d to a partition! [ 8910.931579] blockdev: sending ioctl 125d to a partition! [ 8912.293901] blockdev:
Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support
On Tue, 2012-06-26 at 12:46 +0200, Martin Steigerwald wrote: [...] The current Debian kernels all lack latencytop support: [...] Please consider activating this support again. What do you mean, 'again'? Otherwise someone who wants to use latencytop needs to recompile the kernel which greatly reduces the usefulness of the latencytop package. This costs 1680 or 3360 bytes of non-paged memory for every thread in the system (depending on word size), even if the feature is never actually used. On my laptop, for example, this would be about a megabyte. I really don't think this is a good idea. It is probably possible to change the way the latency records are kept so that this memory is allocated only when needed, but I'm unlikely to find the time to do that. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
