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: <86802c440909251847p421d6523ra40c59e724d566fb@mail.gmail.com>
Date:	Fri, 25 Sep 2009 18:47:55 -0700
From:	Yinghai Lu <yhlu.kernel@...il.com>
To:	Aneurin Price <aneurin.price@...il.com>
Cc:	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 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

YH
--
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/