Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread David Wragg
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes: > The idea is that when it is sure that _only one_ (or some) CPU will access > a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to > contain an entry for that area. > > Although there are (must be) common MTRR entries for the

Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread David Wragg
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes: > I came up with an idea. The MTRRs are per-cpu things. > Ingo Molnar's IRQ affinity code helps binding certain > IRQ sources to certain CPUs. They are implemented as per-cpu things but the Intel manuals say that all cpus should have the same MTRR

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Tigran Aivazian
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr > > echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr > > echo "base=0xfe00 size=0x80 type=write-combining"

Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Gábor Lénárt
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote: > I came up with an idea. The MTRRs are per-cpu things. > Ingo Molnar's IRQ affinity code helps binding certain > IRQ sources to certain CPUs. > > What if the MTRR driver allows per-CPU settings, maybe only on > uncached areas?

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Tigran Aivazian
> On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr this line immediately locks up the machine. But I want to understand where did you get base=0 and size=0x1 from? Shouldn't it be base=0x10 and size=0xfccf according

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Tigran Aivazian
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > Look at the e820 map in the boot log, mark those areas > as write-back and tell me what happens. Here is e820 map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820:

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Tigran Aivazian
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: Look at the e820 map in the boot log, mark those areas as write-back and tell me what happens. Here is e820 map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820:

Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Gbor Lnrt
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote: I came up with an idea. The MTRRs are per-cpu things. Ingo Molnar's IRQ affinity code helps binding certain IRQ sources to certain CPUs. What if the MTRR driver allows per-CPU settings, maybe only on uncached areas? Of

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread Tigran Aivazian
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: echo "base=0 size=0x1 type=write-back" /proc/mtrr echo "base=0x1 size=0x8000 type=write-back" /proc/mtrr echo "base=0xfe00 size=0x80 type=write-combining"

Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread David Wragg
Boszormenyi Zoltan [EMAIL PROTECTED] writes: I came up with an idea. The MTRRs are per-cpu things. Ingo Molnar's IRQ affinity code helps binding certain IRQ sources to certain CPUs. They are implemented as per-cpu things but the Intel manuals say that all cpus should have the same MTRR

Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-12 Thread David Wragg
Boszormenyi Zoltan [EMAIL PROTECTED] writes: The idea is that when it is sure that _only one_ (or some) CPU will access a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to contain an entry for that area. Although there are (must be) common MTRR entries for the main

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-11 Thread Tigran Aivazian
On Wed, 11 Oct 2000, Boszormenyi Zoltan wrote: > On Wed, 11 Oct 2000, Tigran Aivazian wrote: > > I will continue to narrow down by removing some things (like mtrr) from > > the equation. Rik, the problem is that when one enables PAE (or just > > highmem-4G) support on a 4-way 6G RAM machine

36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-11 Thread Boszormenyi Zoltan
On Wed, 11 Oct 2000, Tigran Aivazian wrote: > I will continue to narrow down by removing some things (like mtrr) from > the equation. Rik, the problem is that when one enables PAE (or just > highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower. Will you please try this patch?

36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-11 Thread Boszormenyi Zoltan
On Wed, 11 Oct 2000, Tigran Aivazian wrote: I will continue to narrow down by removing some things (like mtrr) from the equation. Rik, the problem is that when one enables PAE (or just highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower. Will you please try this patch?

Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-11 Thread Tigran Aivazian
On Wed, 11 Oct 2000, Boszormenyi Zoltan wrote: On Wed, 11 Oct 2000, Tigran Aivazian wrote: I will continue to narrow down by removing some things (like mtrr) from the equation. Rik, the problem is that when one enables PAE (or just highmem-4G) support on a 4-way 6G RAM machine becomes