linux-kernel - Re: Regression: kernels since 2.6.26 are unusably slow

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ABD8124.9060108@gmail.com>
Date:	Fri, 25 Sep 2009 20:49:08 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Yinghai Lu <yhlu.kernel@...il.com>
CC:	Aneurin Price <aneurin.price@...il.com>,
	Frans Pop <elendil@...net.nl>, linux-kernel@...r.kernel.org,
	Yinghai Lu <yinghai.lu@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Regression: kernels since 2.6.26 are unusably slow

On 09/25/2009 07:47 PM, Yinghai Lu wrote:
> On Fri, Sep 25, 2009 at 6:02 PM, Aneurin Price<aneurin.price@...il.com>  wrote:
>
>> Hmm. Looking at dmesg for a 'working' kernel includes an interesting part which
>> I foolishly forgot to save, saying that the last 512MB of memory is
>> inaccessible (I was wondering where that last half-gig had gone :-)). I can go
>> and check exactly what it says, but I don't have the energy left for any more
>> reboots today. Anyway, that prompted me to try booting with mem=7168 - and that
>> makes the problem go away. Perhaps that will shed some light on things.
>
> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
> [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000dfee0000 (usable)
> [    0.000000]  BIOS-e820: 00000000dfee0000 - 00000000dfee3000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000dfee3000 - 00000000dfef0000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000dfef0000 - 00000000dff00000 (reserved)
> [    0.000000]  BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000220000000 (usable)
> [    0.000000] DMI 2.4 present.
> [    0.000000] last_pfn = 0x220000 max_arch_pfn = 0x400000000
> [    0.000000] MTRR default type: uncachable
> [    0.000000] MTRR fixed ranges enabled:
> [    0.000000]   00000-9FFFF write-back
> [    0.000000]   A0000-BFFFF uncachable
> [    0.000000]   C0000-CDFFF write-protect
> [    0.000000]   CE000-EFFFF uncachable
> [    0.000000]   F0000-FFFFF write-through
> [    0.000000] MTRR variable ranges enabled:
> [    0.000000]   0 base 100000000 mask FE0000000 write-back
> [    0.000000]   1 base 100000000 mask F00000000 write-back
> [    0.000000]   2 base 000000000 mask F00000000 write-back
> [    0.000000]   3 base 0E0000000 mask FE0000000 uncachable
> [    0.000000]   4 base 0DFF00000 mask FFFF00000 write-through
> [    0.000000]   5 disabled
> [    0.000000]   6 disabled
> [    0.000000]   7 disabled
>
> looks like your MTRR has some problem, and with that WRITE-THROUGH
> there, the trimming e820 will not happen

You might want to see if there's a BIOS update available for that 
system/motherboard..
--
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/