From: Gabriel C <nix.or.die@googlemail.com>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Mika Fischer <mika.fischer@zoopnet.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] x86: mtrr cleanup for converting continuous to discrete layout v7
Date: Wed, 30 Apr 2008 14:04:16 +0200 [thread overview]
Message-ID: <48186040.3050800@googlemail.com> (raw)
In-Reply-To: <86802c440804292125o1539f252g6fbb10fecd8c8c5a@mail.gmail.com>
Yinghai Lu wrote:
> On Tue, Apr 29, 2008 at 9:12 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Yinghai Lu wrote:
>> > please try the patches
>> >
>> > from
>> > http://lkml.org/lkml/2008/4/29/754
>> > http://lkml.org/lkml/2008/4/29/753
>> >
>> > in addtion to
>> >
>> > http://people.redhat.com/mingo/x86.git/README
>> > ( it has v8 already)
>> >
>> > and try with mtrr_gran_size=128m
>>
>> Without any value I get :
>>
>> ...
>>
>> [ 0.000000] Linux version 2.6.25-x86-latest.git-06598-g6a2c2ff-dirty (crazy@thor) (gcc version 4.3.0 (Frugalware Linux) ) #1 SMP PREEMPT Wed Apr 30 05:51:39 CEST 2008
>>
>>
>> [ 0.000000] Command line: root=/dev/sdb1 ro debug vga=0x317
>> [ 0.000000] BIOS-provided physical RAM map:
>> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
>> [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
>> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>> [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used
>> [ 0.000000] max_pfn_mapped = 1228800
>> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
>> [ 0.000000] After WB checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 000000000012c000
>> [ 0.000000] After UC checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 000000000012c000
>> [ 0.000000] MTRR MAP PFN: 00000000000cf800 - 00000000000d0000
>> [ 0.000000] After sorting
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>> [ 0.000000] MTRR MAP PFN: 00000000000cf800 - 00000000000d0000
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 000000000012c000
>> [ 0.000000] range0: 0000000000000000 - 00000000c0000000
>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>> [ 0.000000] range: 00000000c0000000 - 00000000cf600000
>>
>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 128MB, type WB
>> [ 0.000000] Setting variable MTRR 3, base: 3200MB, range: 64MB, type WB
>> [ 0.000000] Setting variable MTRR 4, base: 3264MB, range: 32MB, type WB
>> [ 0.000000] Setting variable MTRR 5, base: 3296MB, range: 16MB, type WB
>> [ 0.000000] Setting variable MTRR 6, base: 3312MB, range: 4MB, type WB
>> [ 0.000000] Setting variable MTRR 7, base: 3316MB, range: 2MB, type WB
>> [ 0.000000] range0: 00000000cf800000 - 00000000df800000
>> [ 0.000000] range: 00000000df800000 - 00000000d0000000
>>
>> [ 0.000000] DONE variable MTRRs
>> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
>> [ 0.000000] After WB checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>>
>> [ 0.000000] After UC checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>>
>> [ 0.000000] After sorting
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>> [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 704MB of RAM.
>>
>> [ 0.000000] update e820 for mtrr
>>
>> [ 0.000000] modified physical RAM map:
>> [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable)
>> [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved)
>> [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved)
>> [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable)
>> [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>> [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>> [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved)
>> [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved)
>>
>> [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved)
>> [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used
>>
>> [ 0.000000] max_pfn_mapped = 1228800
>> [ 0.000000] init_memory_mapping
>>
>> ...
>>
>> [ 20.984343] [drm] Initialized i915 1.6.0 20060119 on minor 0
>> [ 21.450368] mtrr: no more MTRRs available
>>
>> ...
>>
>> with mtrr_gran_size=128m I get :
>>
>> ...
>>
>> [ 0.000000] Linux version 2.6.25-x86-latest.git-06598-g6a2c2ff-dirty (crazy@thor) (gcc version 4.3.0 (Frugalware Linux) ) #1 SMP PREEMPT Wed Apr 30 05:51:39 CEST 2008
>> [ 0.000000] Command line: root=/dev/sdb1 ro debug vga=0x317 mtrr_gran_size=128m
>>
>>
>> [ 0.000000] BIOS-provided physical RAM map:
>> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
>> [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
>> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>> [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used
>> [ 0.000000] max_pfn_mapped = 1228800
>> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
>> [ 0.000000] After WB checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 000000000012c000
>> [ 0.000000] After UC checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 000000000012c000
>> [ 0.000000] MTRR MAP PFN: 00000000000cf800 - 00000000000d0000
>> [ 0.000000] After sorting
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>> [ 0.000000] MTRR MAP PFN: 00000000000cf800 - 00000000000d0000
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 000000000012c000
>> [ 0.000000] range0: 0000000000000000 - 00000000c0000000
>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>> [ 0.000000] range: 00000000c0000000 - 00000000c8000000
>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 128MB, type WB
>> [ 0.000000] rangeX: 00000000d0000000 - 00000000d0000000
>> [ 0.000000] range0: 0000000100000000 - 0000000120000000
>> [ 0.000000] Setting variable MTRR 3, base: 4096MB, range: 512MB, type WB
>> [ 0.000000] range: 0000000120000000 - 0000000128000000
>> [ 0.000000] Setting variable MTRR 4, base: 4608MB, range: 128MB, type WB
>> [ 0.000000] DONE variable MTRRs
>> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
>> [ 0.000000] After WB checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000c8000
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000128000
>> [ 0.000000] After UC checking
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000c8000
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000128000
>> [ 0.000000] After sorting
>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000c8000
>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000128000
>> [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 181MB of RAM.
>>
>> [ 0.000000] update e820 for mtrr
>>
>> [ 0.000000] modified physical RAM map:
>> [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable)
>> [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved)
>> [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved)
>> [ 0.000000] modified: 0000000000100000 - 00000000c8000000 (usable)
>> [ 0.000000] modified: 00000000c8000000 - 00000000cf550000 (reserved)
>> [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>> [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>> [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved)
>> [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved)
>>
>> [ 0.000000] modified: 00000000ffc00000 - 0000000100000000 (reserved)
>> [ 0.000000] modified: 0000000100000000 - 0000000128000000 (usable)
>> [ 0.000000] modified: 0000000128000000 - 000000012c000000 (reserved)
>>
>> [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 256, 819200) 3 entries of 256 used
>> [ 0.000000] Entering add_active_range(0, 1048576, 1212416) 3 entries of 256 used
>>
>> [ 0.000000] max_pfn_mapped = 1228800
>> [ 0.000000] init_memory_mapping
>>
>> ...
>>
>> I will try tomorrow some more boot options but now I need some sleep ;)
>
> thanks. let's try different mtrr_chunk_size/mtrr_gran_size to get
> back more ram.
> under mtrr_gran_size=128m, does the your X server work well..., fast or slow?
Yes X is fine and fast , it is even fine ( slower from my felling ) when I lose the 704MB.
In general with x86-latest.git tree things seems faster on that box , maybe there are some other bug fixes too.
I've tested some mtrr_chunk_size/mtrr_gran_size combos, dmesg's are uploaded there :
http://frugalware.org/~crazy/dmesg/mtrr/
Also setting lower values on mtrr_gran_size seems to give more RAM back ,
mtrr_chunk_size 256/512 eats 704 MB and 128 doesn't seems to do something ?
Other things I noticed ( probably you could add a note about in kernel-parameter.txt or some doc file ):
Setting mtrr_gran_size to high , on my box >=512m hangs the box on boot ,
setting it to low , on my box <=8m , will cause X to die with such a message :
xf86MapVidMem: Could not mmap framebuffer (0xd0000000,0x10000000) (Invalid argument)
If you want I can test such values for mtrr_chunk_size too , just let me know.
To be honest I'm even fine when losing 700 - 800 MB as long X and everything else does work.
The other alternative for me for that problem without your patches will be to buy new ram ( 2 x 1G )
and then I lose near 2,3G compared to now or live with broken X until xorg-server will support and
*work fine* with PAT ( most probably not that soon ).
Gabriel
next prev parent reply other threads:[~2008-04-30 12:04 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 6:37 [PATCH] x86: mtrr cleanup for converting continuous to discrete layout Yinghai Lu
2008-04-28 9:06 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v2 Yinghai Lu
2008-04-28 13:08 ` Ingo Molnar
2008-04-28 13:49 ` Arjan van de Ven
2008-04-28 15:28 ` Mika Fischer
2008-04-28 5:50 ` Arjan van de Ven
2008-04-28 16:01 ` Gabriel C
2008-04-28 16:28 ` Mika Fischer
2008-04-28 19:44 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v3 Yinghai Lu
2008-04-28 20:15 ` Ingo Molnar
2008-04-28 20:18 ` Yinghai Lu
2008-04-28 20:29 ` Ingo Molnar
2008-04-28 20:16 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v4 Yinghai Lu
2008-04-28 22:05 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5 Yinghai Lu
2008-04-28 22:36 ` Randy Dunlap
2008-04-28 22:47 ` Yinghai Lu
2008-04-29 2:42 ` Andrew Morton
2008-04-29 3:01 ` Yinghai Lu
[not found] ` <200804290157.30651.yhlu.kernel@gmail.com>
2008-04-29 8:59 ` [PATCH 2/2] x86: fix trimming e820 with MTRR holes Yinghai Lu
2008-04-29 11:35 ` Ingo Molnar
2008-04-29 17:18 ` Yinghai Lu
2008-04-29 17:20 ` Yinghai Lu
2008-04-30 3:25 ` [PATCH] x86: fix trimming e820 with MTRR holes. - fix Yinghai Lu
2008-04-30 12:09 ` Ingo Molnar
2008-04-29 9:00 ` [PATCH 1/2] x86: mtrr cleanup for converting continuous to discrete layout v7 Yinghai Lu
2008-04-29 9:47 ` Gabriel C
2008-04-29 10:30 ` Yinghai Lu
2008-04-29 10:56 ` Yinghai Lu
2008-04-29 11:26 ` Ingo Molnar
2008-04-29 11:51 ` Gabriel C
2008-04-29 17:11 ` Yinghai Lu
2008-04-29 20:25 ` Gabriel C
2008-04-29 21:49 ` Yinghai Lu
2008-04-29 23:56 ` Gabriel C
2008-04-30 0:06 ` Gabriel C
2008-04-30 0:38 ` Yinghai Lu
2008-04-30 1:02 ` Gabriel C
2008-04-30 3:00 ` Yinghai Lu
2008-04-30 3:29 ` Yinghai Lu
2008-04-30 4:12 ` Gabriel C
2008-04-30 4:25 ` Yinghai Lu
2008-04-30 12:04 ` Gabriel C [this message]
2008-04-30 16:26 ` Yinghai Lu
2008-04-30 0:13 ` Yinghai Lu
2008-04-29 10:52 ` [PATCH 1/2] x86: mtrr cleanup for converting continuous to discrete layout v8 Yinghai Lu
2008-04-29 13:07 ` Ingo Molnar
2008-04-29 17:25 ` Yinghai Lu
2008-04-29 20:46 ` Randy Dunlap
2008-04-29 21:54 ` Yinghai Lu
2008-04-30 3:25 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v8 - fix Yinghai Lu
2008-04-30 12:09 ` Ingo Molnar
2008-05-01 8:00 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete - auto detect Yinghai Lu
2008-05-01 11:45 ` Gabriel C
2008-05-02 0:06 ` Yinghai Lu
2008-05-02 0:29 ` Gabriel C
2008-05-02 0:35 ` Yinghai Lu
2008-05-02 1:18 ` Gabriel C
2008-05-02 1:55 ` Yinghai Lu
2008-05-01 12:09 ` Mika Fischer
2008-05-01 16:35 ` Yinghai Lu
2008-05-01 16:59 ` Mika Fischer
2008-05-01 17:40 ` Yinghai Lu
2008-05-01 15:09 ` Randy Dunlap
2008-05-01 16:38 ` Yinghai Lu
2008-05-01 18:57 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete - auto detect v2 Yinghai Lu
2008-05-01 19:42 ` H. Peter Anvin
2008-05-01 21:02 ` Yinghai Lu
2008-05-01 21:10 ` H. Peter Anvin
2008-05-01 21:20 ` Yinghai Lu
2008-05-01 21:26 ` H. Peter Anvin
2008-05-01 21:31 ` Yinghai Lu
2008-05-01 21:33 ` H. Peter Anvin
2008-05-01 21:44 ` Yinghai Lu
2008-05-01 21:49 ` H. Peter Anvin
2008-05-01 22:52 ` Yinghai Lu
2008-05-01 22:57 ` H. Peter Anvin
2008-05-01 23:10 ` Yinghai Lu
2008-05-02 0:52 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete - auto detect v3 Yinghai Lu
2008-05-02 9:40 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete - auto detect v4 Yinghai Lu
2008-04-29 19:00 ` [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5 Eric W. Biederman
2008-04-29 20:04 ` Yinghai Lu
2008-04-29 20:29 ` Eric W. Biederman
2008-04-29 21:57 ` Yinghai Lu
2008-04-29 22:09 ` Ingo Molnar
2008-04-29 22:18 ` Yinghai Lu
2008-04-29 22:14 ` Eric W. Biederman
2008-04-29 22:54 ` Thomas Gleixner
2008-04-30 1:16 ` Eric W. Biederman
2008-04-30 9:57 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48186040.3050800@googlemail.com \
--to=nix.or.die@googlemail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.fischer@zoopnet.de \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.