Hello,
I have been following the mailing list for some time and seen 1
reference to big memory related slowdowns in the 2.4.x series of kernels
which seem related. Waiting for the latest version of the kernel to see
if it would clear up the issues which I believe are related to mtrr
mis-assigning regions has not fixed the issue.
I have been experiencing severe performance slowdowns when using the 4GB
or 64GB memory options in the stock 2.4.4 kernel. When using the 1GB
option performace is ok, but unfortuntly does not allow access to the 8GB
which are installed in the machine. The severe memory problems seem to be
out of line with the overhead for the three layer memory addressing in the
64GB memory scheme. Simple commands such as 'ls' take half a second
instead of the customary .009 seconds in the lower memory configuration.
The system is:
4 x 700Mhz Xeon PIII w/2MB cache
8GB ECC RAM
Supermicro S2QR6 ServerWorks ServerSet III HE Chipset MB
AMI Bios
3-Ware raid controller running raid5 in hardware
mtrr is enabled in all situations and /proc/mtrr has always (in "off",
"4GB" and "64GB" memory modes) said:
borg.corp[root]~# cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg01: base=0xfc000000 (4032MB), size= 64MB: uncachable, count=1
There is no problem with the system registering the whole amount of RAM,
and we haven't had any problem with crashes in the limited tests we have
done. The interesting part is that certain system calls take long periods
to complete, this was most evident when stracing the command.
The system physical RAM information is as follows:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000fcdf0000 (usable)
BIOS-e820: 00000000fcdf0000 - 00000000fcdff000 (ACPI data)
BIOS-e820: 00000000fcdff000 - 00000000fce00000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000200000000 (usable)
In the message to the list on Jan 15, 2001 by Mr. Ingo he recommended
another person with slowdown problems to force a memory map on the system.
We looked throught the kernel source and found that the mem= commands can
only parse and return long words, not long long words. We therefore only
looked to use the following memory areas:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 0000000000100000 - 00000000fcdf0000 (usable)
for a total of approximently 4GB.
This yielded a lilo line that looks like:
append="mem=exactmap mem=0x0009fc00@0x00000000 mem=0xfccf0000@0x00100000"
We had hoped that this would yield faster performance and would allow us
to manually add using echo "..." >| /proc/mtrr the final 4GB block:
BIOS-e820: 0000000100000000 - 0000000200000000 (usable)
Unfortunently when we ran this configuration the /proc/mtrr looked the
same as before. The kernel looked like it knew it was passed the correct
lines and I am still at a loss to make my MTRR look like the MTRR settings
that was talked of.
I have included 2 system boot logs as attachments to this letter. One is
with the exactmap lines, the other is the kernel booting normally. I hope
that this will cover anything I have not been able to cover. Any help is
greatly appreciated.
Shay
This archive was generated by hypermail 2b29 : Tue May 15 2001 - 21:00:24 EST