lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-id: <46FD90E7.6090009@shaw.ca>
Date:	Fri, 28 Sep 2007 17:40:23 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Sergey Popov <faijeya@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: General slowness with using 64Gb HIGHMEM option on 32-bit kernel

Sergey Popov wrote:
> Short description: after recompiling 32-bit kernel with 64Gb highmem
> support and rebooting into it, OS started working very much slower
> then before.
> 
> Specifications: Intel Core 2 Duo E6600@2,4Ghz on Intel i965Q-based
> motherboard. 6Gb of DDR2 RAM, 2x1Gb+2x2Gb, dual-channel.
> Vector Linux 5.8 (Slackware Linux 11-based), 2.6.20.3 kernel.
> 
> Long description: after recompiling 32-bit 2.6.20.3 kernel with 64Gb
> highmem option and rebooting into it, booting process froze on udevd.
> After booting up from CD and disabling rc.udev, system started, but
> it's work after rc.M script sarted was 5-10 times slower then usual.
> top showed, that processes are taking much more CPU% time then usual.
> I tried downloading the newest stable kernel - 2.6.22.9 - hoping, that
> it would solve the problem. I downloaded it, booted from CD, and
> compiled it with 64Gb highmem support. I felt some speed improvement,
> but if on 2.6.20.3 machine performed like P166, now it is working like
> P2-350.
> I've found a similar problem, described on lkml -
> http://lkml.org/lkml/2007/5/30/5 . But, unfortunately, it is x86_64
> related and contains no clues for me.
> 
> Moving to 64-bit distro is rather unpleasant - as there is an option
> in 32-bit kernel, it should work ;) .
> 
> What tests should I run to help investigate this problem?

Make sure your BIOS is up to date. If so, post your dmesg output and the 
contents of /proc/mtrr. There are a number of Intel boards which 
have/had BIOS bugs where the BIOS didn't set up the MTRRs to mark all 
RAM as write-back. This results in the last bit of memory being 
uncacheable and causes a major performance drop.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ