Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine [solved]
Robert Hancock wrote: Peter Rabbitson wrote: reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. I sincerely apologize for not paying enough attention. Intel has fixed this issue 2 BIOS revisions ago[1], kudos to Suren Karapetyan for pointing this out. I just upgraded the BIOS and it indeed solves the problem. The mtrr still seems not to be going over 4000MB, but everything works without any visible slowdowns at all. Here is how the mtrr and the relevant dmesg line look like now: reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 (there is no reg05) ... Memory: 4024568k/4063168k available (2894k kernel code, 37456k reserved, 930k data, 252k init, 3145664k highmem) ... Thank you for the help! Peter [1] http://downloadcenter.intel.com/Detail_Desc.aspx?agr=N=Yes=1640=11261=All=All%20Operating%20Systems=eng - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine [solved]
Robert Hancock wrote: Peter Rabbitson wrote: reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. I sincerely apologize for not paying enough attention. Intel has fixed this issue 2 BIOS revisions ago[1], kudos to Suren Karapetyan for pointing this out. I just upgraded the BIOS and it indeed solves the problem. The mtrr still seems not to be going over 4000MB, but everything works without any visible slowdowns at all. Here is how the mtrr and the relevant dmesg line look like now: reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 (there is no reg05) ... Memory: 4024568k/4063168k available (2894k kernel code, 37456k reserved, 930k data, 252k init, 3145664k highmem) ... Thank you for the help! Peter [1] http://downloadcenter.intel.com/Detail_Desc.aspx?agr=NInst=YesProductID=1640DwnldID=11261strOSs=AllOSFullName=All%20Operating%20Systemslang=eng - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Peter Rabbitson wrote: Robert Hancock wrote: Peter Rabbitson wrote: H. Peter Anvin wrote: What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. Ah, it all makes sense now. In this case I assume mem=4000 is perfectly safe and usable for the time being. In the beginning I tried with mem=4g, which obviously did not work. If anyone is interested in adding an exception/workaround for this particular motherboard, I'd be happy to help with testing. I have added more information about the system: current kernel config [1], output of `lspci -vv`[2], dmesg with mem=4000[3]. Thank you! Peter There was a patch floating around recently to detect the case where the MTRRs don't map all of RAM as write-back, automatically cap the memory used by the kernel to what is mapped and print some loud warnings.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Robert Hancock wrote: Peter Rabbitson wrote: H. Peter Anvin wrote: What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. Ah, it all makes sense now. In this case I assume mem=4000 is perfectly safe and usable for the time being. In the beginning I tried with mem=4g, which obviously did not work. If anyone is interested in adding an exception/workaround for this particular motherboard, I'd be happy to help with testing. I have added more information about the system: current kernel config [1], output of `lspci -vv`[2], dmesg with mem=4000[3]. Thank you! Peter [1] http://rabbit.us/pool/4g/config-2.6.21.5.arzamas.6.txt [2] http://rabbit.us/pool/4g/lspci_4000.txt [3] http://rabbit.us/pool/4g/dmesg_4000.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Robert Hancock wrote: Peter Rabbitson wrote: H. Peter Anvin wrote: What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. Ah, it all makes sense now. In this case I assume mem=4000 is perfectly safe and usable for the time being. In the beginning I tried with mem=4g, which obviously did not work. If anyone is interested in adding an exception/workaround for this particular motherboard, I'd be happy to help with testing. I have added more information about the system: current kernel config [1], output of `lspci -vv`[2], dmesg with mem=4000[3]. Thank you! Peter [1] http://rabbit.us/pool/4g/config-2.6.21.5.arzamas.6.txt [2] http://rabbit.us/pool/4g/lspci_4000.txt [3] http://rabbit.us/pool/4g/dmesg_4000.txt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Peter Rabbitson wrote: Robert Hancock wrote: Peter Rabbitson wrote: H. Peter Anvin wrote: What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. Ah, it all makes sense now. In this case I assume mem=4000 is perfectly safe and usable for the time being. In the beginning I tried with mem=4g, which obviously did not work. If anyone is interested in adding an exception/workaround for this particular motherboard, I'd be happy to help with testing. I have added more information about the system: current kernel config [1], output of `lspci -vv`[2], dmesg with mem=4000[3]. Thank you! Peter There was a patch floating around recently to detect the case where the MTRRs don't map all of RAM as write-back, automatically cap the memory used by the kernel to what is mapped and print some loud warnings.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Peter Rabbitson wrote: H. Peter Anvin wrote: Peter Rabbitson wrote: I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
H. Peter Anvin wrote: Peter Rabbitson wrote: I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Peter Rabbitson wrote: > > I have captured dmesg output without mem[5], with mem=3900M[6] and > mem=2048M[7]. > What does /proc/mtrr look like in the two cases? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Terrible IO performance when using 4GB of RAM on a 32 bit machine
Hello everyone, I hope this question is not too basic for the intended audience. I have a server with an Intel SE7210TP1-E motherboard[1] and a single 3.4GHz P4 CPU[2]. I am currently running a vanilla 2.6.21.5 kernel with SMP/HT. Two patches are applied: one is a SATA driver[3] and the other is a stable kernel bugfix[4]. When I upgraded my memory to 4GB I experienced abysmal performance at the IO layer across all block devices. CPU and network performance seem to be unaffected. Booting the system with mem=3900M fixes the issue, but I wanted to get to the root of it. I have a 4 drive raid array with LVM on top, which after tuning consistently delivers 210MB/s sequential read performance. If I omit the mem option and let the kernel autodetect all 4GB of memory, performance drops to about 4MB/s. A drop to 1MB/s is also observed on direct disk access (dd if=/dev/sdX). Two of the disks are connected the the on-board SATA ports and two to a Highpoint RocketRaid 1820A Card. A backup hard drive connected to the on-board IDE is suffering the same problems, so it should be something more fundamental. What I have tried so far in various combinations: o a kernel without SMP/HT support o a kernel with HIGHPTE=y o different timer frequencies (100, 1000) o older kernel version (2.6.18) I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. Overall the system did not exhibit any problems in the last 2 years it operated, and it seems to be running fine with mem=3900M, which is in effect for about a month now. I would appreciate any suggestions on how to troubleshoot this further, or requests for additional information about the system. TIA Peter [1] http://download.intel.com/support/motherboards/server/se7210tp1-e/sb/tpsse7210tp1e20.pdf [2] http://rabbit.us/pool/4g/cpuinfo.txt [3] http://www.highpoint-tech.com/BIOS_Driver/rr1820a/Linux/rr18xx-opensource-v1.17-0123.tgz [4] http://www.mail-archive.com/[EMAIL PROTECTED]/msg08186.html [5] http://rabbit.us/pool/4g/dmesg_nomem.txt [6] http://rabbit.us/pool/4g/dmesg_3900.txt [7] http://rabbit.us/pool/4g/dmesg_2048.txt Follows a diff of [6] and [5]: --- dmesg_3900.txt 2007-06-21 19:04:33.0 +0200 +++ dmesg_nomem.txt 2007-06-21 19:04:36.0 +0200 @@ -20,41 +20,24 @@ BIOS-e820: fbeff000 - fbf0 (ACPI NVS) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) - limit_regions start: - 0009dc00 (usable) - limit_regions start: 0009dc00 - 000a (reserved) - limit_regions start: 000e4000 - 0010 (reserved) - limit_regions start: 0010 - fbef (usable) - limit_regions start: fbef - fbeff000 (ACPI data) - limit_regions start: fbeff000 - fbf0 (ACPI NVS) - limit_regions start: fee0 - fee01000 (reserved) - limit_regions start: ffb0 - 0001 (reserved) - limit_regions endfor: - 0009dc00 (usable) - limit_regions endfor: 0009dc00 - 000a (reserved) - limit_regions endfor: 000e4000 - 0010 (reserved) - limit_regions endfor: 0010 - f3c0 (usable) -user-defined physical RAM map: - user: - 0009dc00 (usable) - user: 0009dc00 - 000a (reserved) - user: 000e4000 - 0010 (reserved) - user: 0010 - f3c0 (usable) -3004MB HIGHMEM available. +3134MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 -Entering add_active_range(0, 0, 998400) 0 entries of 256 used +Entering add_active_range(0, 0, 1031920) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 - HighMem229376 -> 998400 + HighMem229376 -> 1031920 early_node_map[1] active PFN ranges -0:0 -> 998400 -On node 0 totalpages: 998400 +0:0 -> 1031920 +On node 0 totalpages: 1031920 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 - HighMem zone: 6008 pages used for memmap - HighMem zone: 763016 pages, LIFO batch:31 + HighMem zone: 6269 pages used for memmap + HighMem zone: 796275 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP 000F87E0, 0014 (r0 ACPIAM) ACPI: RSDT FBEF, 0030 (r1 A M I OEMRSDT 7000529 MSFT 97) @@ -83,9 +66,9 @@ ACPI: IRQ10 used by override. Enabling APIC mode: Flat. Using 2 I/O APICs Using ACPI (MADT) for SMP configuration information -Allocating PCI resources starting at f400 (gap: f3c0:0c40) -Built 1 zonelists. Total pages: 990600 -Kernel command line: root=/dev/md0 ro vga=307 mem=3900M +Allocating PCI resources starting at fc00 (gap:
Terrible IO performance when using 4GB of RAM on a 32 bit machine
Hello everyone, I hope this question is not too basic for the intended audience. I have a server with an Intel SE7210TP1-E motherboard[1] and a single 3.4GHz P4 CPU[2]. I am currently running a vanilla 2.6.21.5 kernel with SMP/HT. Two patches are applied: one is a SATA driver[3] and the other is a stable kernel bugfix[4]. When I upgraded my memory to 4GB I experienced abysmal performance at the IO layer across all block devices. CPU and network performance seem to be unaffected. Booting the system with mem=3900M fixes the issue, but I wanted to get to the root of it. I have a 4 drive raid array with LVM on top, which after tuning consistently delivers 210MB/s sequential read performance. If I omit the mem option and let the kernel autodetect all 4GB of memory, performance drops to about 4MB/s. A drop to 1MB/s is also observed on direct disk access (dd if=/dev/sdX). Two of the disks are connected the the on-board SATA ports and two to a Highpoint RocketRaid 1820A Card. A backup hard drive connected to the on-board IDE is suffering the same problems, so it should be something more fundamental. What I have tried so far in various combinations: o a kernel without SMP/HT support o a kernel with HIGHPTE=y o different timer frequencies (100, 1000) o older kernel version (2.6.18) I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. Overall the system did not exhibit any problems in the last 2 years it operated, and it seems to be running fine with mem=3900M, which is in effect for about a month now. I would appreciate any suggestions on how to troubleshoot this further, or requests for additional information about the system. TIA Peter [1] http://download.intel.com/support/motherboards/server/se7210tp1-e/sb/tpsse7210tp1e20.pdf [2] http://rabbit.us/pool/4g/cpuinfo.txt [3] http://www.highpoint-tech.com/BIOS_Driver/rr1820a/Linux/rr18xx-opensource-v1.17-0123.tgz [4] http://www.mail-archive.com/[EMAIL PROTECTED]/msg08186.html [5] http://rabbit.us/pool/4g/dmesg_nomem.txt [6] http://rabbit.us/pool/4g/dmesg_3900.txt [7] http://rabbit.us/pool/4g/dmesg_2048.txt Follows a diff of [6] and [5]: --- dmesg_3900.txt 2007-06-21 19:04:33.0 +0200 +++ dmesg_nomem.txt 2007-06-21 19:04:36.0 +0200 @@ -20,41 +20,24 @@ BIOS-e820: fbeff000 - fbf0 (ACPI NVS) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) - limit_regions start: - 0009dc00 (usable) - limit_regions start: 0009dc00 - 000a (reserved) - limit_regions start: 000e4000 - 0010 (reserved) - limit_regions start: 0010 - fbef (usable) - limit_regions start: fbef - fbeff000 (ACPI data) - limit_regions start: fbeff000 - fbf0 (ACPI NVS) - limit_regions start: fee0 - fee01000 (reserved) - limit_regions start: ffb0 - 0001 (reserved) - limit_regions endfor: - 0009dc00 (usable) - limit_regions endfor: 0009dc00 - 000a (reserved) - limit_regions endfor: 000e4000 - 0010 (reserved) - limit_regions endfor: 0010 - f3c0 (usable) -user-defined physical RAM map: - user: - 0009dc00 (usable) - user: 0009dc00 - 000a (reserved) - user: 000e4000 - 0010 (reserved) - user: 0010 - f3c0 (usable) -3004MB HIGHMEM available. +3134MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 -Entering add_active_range(0, 0, 998400) 0 entries of 256 used +Entering add_active_range(0, 0, 1031920) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 - HighMem229376 - 998400 + HighMem229376 - 1031920 early_node_map[1] active PFN ranges -0:0 - 998400 -On node 0 totalpages: 998400 +0:0 - 1031920 +On node 0 totalpages: 1031920 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 - HighMem zone: 6008 pages used for memmap - HighMem zone: 763016 pages, LIFO batch:31 + HighMem zone: 6269 pages used for memmap + HighMem zone: 796275 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP 000F87E0, 0014 (r0 ACPIAM) ACPI: RSDT FBEF, 0030 (r1 A M I OEMRSDT 7000529 MSFT 97) @@ -83,9 +66,9 @@ ACPI: IRQ10 used by override. Enabling APIC mode: Flat. Using 2 I/O APICs Using ACPI (MADT) for SMP configuration information -Allocating PCI resources starting at f400 (gap: f3c0:0c40) -Built 1 zonelists. Total pages: 990600 -Kernel command line: root=/dev/md0 ro vga=307 mem=3900M +Allocating PCI resources starting at fc00 (gap:
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Peter Rabbitson wrote: I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. What does /proc/mtrr look like in the two cases? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
H. Peter Anvin wrote: Peter Rabbitson wrote: I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
Peter Rabbitson wrote: H. Peter Anvin wrote: Peter Rabbitson wrote: I have captured dmesg output without mem[5], with mem=3900M[6] and mem=2048M[7]. What does /proc/mtrr look like in the two cases? Identical for mem=3900 and without it. reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc000 (3072MB), size= 512MB: write-back, count=1 reg03: base=0xe000 (3584MB), size= 256MB: write-back, count=1 reg04: base=0xf000 (3840MB), size= 128MB: write-back, count=1 reg05: base=0xf800 (3968MB), size= 32MB: write-back, count=1 Looks like another case of bad MTRRs on an Intel motherboard? The BIOS is marking only memory up to 4000MB as cacheable, but the actual memory extends up to about 4031MB. Therefore anything that accesses the top 31MB of memory will run very slow. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
