Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 110661 - 2.6.13 runs slow on some HT P4, upstream patch(es) available
Summary: 2.6.13 runs slow on some HT P4, upstream patch(es) available
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Daniel Drake (RETIRED)
URL: http://bugzilla.kernel.org/show_bug.c...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-27 18:28 UTC by Iain Buchanan
Modified: 2005-12-02 09:31 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Iain Buchanan 2005-10-27 18:28:29 UTC
Ever since the introduction of the CONFIG_HZ_1000 option, my hyperthreaded P4
laptop has been unable to run the kernels because they're excruciatingly slow!

I tracked down this bug on kernel.org:
http://bugzilla.kernel.org/show_bug.cgi?id=5165
which offers two patches to fix the problem.

apparently its not related to all HT systems, only some.

be careful, as it stuffed suspend and resume for me, which used to work flawlessly.

I've tried 2.6.13 gentoo r2, r3, & r5 - same results with all.
I applied the patches mentioned on bugzilla.kernel.org to 2.6.13-gentoo-r3.

Reproducible: Always
Steps to Reproduce:
1. compile any 2.6.13 kernel
2. boot to said kernel
Actual Results:  
From boot, kernel entire system runst about 10x slower.


$ emerge info
Portage 2.0.53_rc6 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2,
2.6.13-gentoo-r3 i686)
=================================================================
System uname: 2.6.13-gentoo-r3 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz
Gentoo Base System version 1.12.0_pre9
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python:     2.3.5, 2.4.2
sys-apps/sandbox:    1.2.13
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c
/etc/env.d"
CXXFLAGS="-march=pentium4 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks fixpackages sandbox sfperms strict"
GENTOO_MIRRORS="ftp://arion/pub/gentoo-portage/
ssh://gauntlet.pcorp.com.au/usr/portage/ ftp://mirror.isp.net.au/pub/gentoo/
ftp://gg3.net/pub/linux/gentoo/ ftp://gentoo.ccccom.com
ftp://ftp.ussg.iu.edu/pub/linux/gentoo"
LANG="en_AU"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.au.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa apache2 arts avi bash-completion berkdb bitmap-fonts
bluetooth cdr crypt cups curl directfb dvd dvdr eds emboss encode esd evo fam
flac foomaticdb fortran ftp gdbm gif gnome gpm gstreamer gtk gtk2 guile
imagemagick imlib ipv6 irmc java jpeg libg++ libwww mad mikmod mmx motif mozilla
mozsvg mp3 mpeg mysql ncurses nfs nls ogg oggvorbis opengl pam pdflib perl php
png postgres python quicktime readline samba sdl spell sse ssl svg svga tcltk
tcpd tetex tiff truetype truetype-fonts type1-fonts udev vorbis win32codecs xml
xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS
Comment 1 Daniel Drake (RETIRED) gentoo-dev 2005-10-28 00:54:20 UTC
The patches on that bug are not upstream yet the bug is marked as CODE_FIX.
Could you please test 2.6.14 and see if the bug has been fixed another way?
Comment 2 Iain Buchanan 2005-10-28 23:35:34 UTC
> The patches on that bug are not upstream yet the bug is marked as CODE_FIX.

oh, I was only guessing what upstream means exactly.

> Could you please test 2.6.14 and see if the bug has been fixed another way?

OK, I tried vanilla 2.6.14_rc5, and it has the same behaviour (takes very long
to boot, gdm takes 30s or more to display login screen, etc).  Should I follow
this up here, or at http://bugzilla.kernel.org/show_bug.cgi?id=5165 or both?

Funny thing, it _seems_ to be 10x slower, but sound still plays ok, and typing
on keyboard is still ok, but I don't know much about these things...
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2005-10-29 06:57:47 UTC
will track upstream bug
Comment 4 Antek Grzymała (antoszka) 2005-11-13 17:28:48 UTC
It can also be much slower. Doing this: dd if=/dev/urandom of=/dev/null bs=1M
count=4 takes less than a second on my healthy system and about 43 seconds on
the slowed-down one.

I can also confirm the bug is still there with gentoo-sources-2.6.14-r2. Please
change the resolution to something different than RESOLVED UPSTREAM (as it is
*not*).

Thanks,

[a]
Comment 5 Iain Buchanan 2005-11-13 17:45:57 UTC
I just installed vanilla-sources 2.6.15_rc1, and the "slowness" is still there.
 Aforementioned patches still work however.

> Please change the resolution to something different than RESOLVED UPSTREAM (as
it is *not*).

I think it's marked RESOLVED UPSTREAM because 

> will track upstream bug

ie. there's no point in having two bugs for it, so lets track the upstream one.

However, I don't use bugzilla all that much, so this interpretation may be wrong :)

I.
Comment 6 Antek Grzymała (antoszka) 2005-11-14 00:52:31 UTC
> I think it's marked RESOLVED UPSTREAM because 
> > will track upstream bug
> ie. there's no point in having two bugs for it, so lets track the upstream one.

Well, if we were just watching vanilla kernel sources, than yes, you'd probably
be right. But since we're looking into gentoo-sources, which have their own
patchset, than I guess the patches fixing this error could go into
gentoo-sources as well. If they break swsuspend2 than it should be perhaps be
done via exclusive USE flags (fix my hyperthreading || have swsuspend working).

Still -- baffles the blimpers out of me, how such a *serious* bug could persist
in at least two releases of the kernel. Anybody listening out there?

[a]
Comment 7 Daniel Drake (RETIRED) gentoo-dev 2005-11-14 07:38:35 UTC
I don't have a good knowledge of ACPI, and I don't have much clue about the
implications of those patches.

There may well be a reason that they are in the test tree and *not* yet in
Linus' tree.

Without being able to fully understand the patches, I won't add them to
gentoo-sources until they are pushed to Linus' tree (which generally means they
are fully expected to work). This is standard policy for gentoo-sources. Sorry
for the inconvenience this bug is causing you, I expect it will be fixed soon...
Comment 8 John Mylchreest (RETIRED) gentoo-dev 2005-11-15 10:47:11 UTC
*** Bug 112604 has been marked as a duplicate of this bug. ***
Comment 9 Sumit Khanna 2005-11-15 12:14:01 UTC
The bug I entered, 112604, was marked a duplicate of this bug. However in that
bug, I state that using "top" or cat /proc/cpuinfo shows that the second
processor IS NOT THERE. Has 2.6.13 changed so that an HT processor now only
shows up as one processor? If you guy still see two processor in /proc/cpuinfo,
please unmark that bug as a duplicate and reopen it.
Comment 10 Daniel Drake (RETIRED) gentoo-dev 2005-12-02 03:33:09 UTC
fixed upstream
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2005-12-02 09:31:51 UTC
Fixed in genpatches-2.6.14-5 / gentoo-sources-2.6.14-r4