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-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Wed Jun 6 10:34:53 CEST 2012
** USB devices:
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader)
Bus 002 Device 003: ID 04d9:1603 Holtek Semiconductor, Inc. Keyboard
Bus 002 Device 004: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse (M-BT58)
Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-image-3.4-trunk-amd64 depends on:
ii debconf [debconf-2.0] 1.5.43
ii initramfs-tools [linux-initramfs-tool] 0.106
ii kmod 8-2
ii linux-base 3.5
ii module-init-tools 8-2
Versions of packages linux-image-3.4-trunk-amd64 recommends:
ii firmware-linux-free 3
Versions of packages linux-image-3.4-trunk-amd64 suggests:
ii grub-pc 1.99-22.1
ii linux-doc-3.4 3.4.1-1~experimental.1
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120626104614.23032.7998.reportbug@mango.of.teami x.net">http://lists.debian.org/20120626104614.23032.7998.reportbug@mango.of.teami x.net
06-27-2012, 03:11 AM
Ben Hutchings
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.
06-27-2012, 08:34 AM
Martin Steigerwald
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.
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201206271034.43139.ms@teamix.de">http://lists.debian.org/201206271034.43139.ms@teamix.de
06-27-2012, 02:04 PM
Ben Hutchings
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.