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] [day] [month] [year] [list]
Date:	Sat, 26 Sep 2009 23:51:45 +0100
From:	Aneurin Price <aneurin.price@...il.com>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	Yinghai Lu <yhlu.kernel@...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 Sat, Sep 26, 2009 at 03:49, Robert Hancock <hancockrwd@...il.com> wrote:
> 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..
>

Slightly surprisingly to me, after spending two and a half hours figuring out a
way to update the BIOS, it actually worked:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009dc00 (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 000000000 mask F00000000 write-back
[    0.000000]   1 base 0E0000000 mask FE0000000 uncachable
[    0.000000]   2 base 100000000 mask F00000000 write-back
[    0.000000]   3 base 200000000 mask FE0000000 write-back
[    0.000000]   4 base 0DFF00000 mask FFFF00000 uncachable
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled

I do wish I understood this better, but I suppose that'll have to be a topic for
future research.

Given that I'm no longer having the problem, this isn't of pressing importance
to me so is purely informational:

CONFIG_MTRR_SANITIZER didn't help[0], though I didn't try changing the value of
MTRR_SANITIZER_SPARE_REG_NR_DEFAULT. I also tried mtrr-uncover which I learned
about from http://kerneltrap.org/mailarchive/linux-kernel/2008/9/30/3454074, and
that didn't help either. However, the thing that makes me bother mentioning all
this is that I tried booting Windows XP (64bit) before updating the BIOS, and
that worked fine with the full 8GB of RAM. This indicates to me that whatever
the problem, it wasn't insurmountable, so in principle Linux could do better.

If it doesn't seem worth looking into further then that's perfectly
understandable, but if anyone is interested and would like any more information,
let me know.

Thank you all for your suggestions,
Nye



[0] Google indicated that passing the boot param 'enable_mtrr_cleanup' would be
appropriate; I don't know if that's correct, and I don't really understand the
wording on MTRR_SANITIZER_ENABLE_DEFAULT. I got the impression that the optional
0 or 1 value just means 'enable MTRR cleanup or not', and is overridden by the
boot parameter. Maybe that option would be worth clarifying?
--
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/