Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
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 memory > and the commonly accessed mmio register areas. > > The idea came because fiddling with MTRRs quickly revaled that > only 8 variable ones exist. I see. I think there is a more straightforward solution: PAT does the same thing as MTRRs, but has no such "number of ranges" limitation --- it lets you set the memory type on a page-by-page basis. If the number of MTRRs becomes a problem (anyone know how many the P4 has?), then the real solution is to implement PAT support. IIRC, only the PPro, the first PII model (Klamath?), and the first Celeron model have MTRR but not PAT (Athlon has PAT, but /proc/cpuinfo misreports it as "fcmov", at least in 2.2.14; Xeons always had PAT). David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
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 settings. They also give pseudo-code for how to update them on an SMP system, which mtrr.c follows. If the BIOS has set them up differently at boot time, mtrr.c will complain and copy the MTRR settings of CPU0 to the others. Regards, David Wragg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
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 course the real memory should be cached in > every CPU to avoid slowdowns. So that if you set that eth0's > IRQ will be handled by CPU1, the MTRRs of CPU1 will be set > accordingly, and the other CPUs will not care about eth0, > so they do not need eth0's MTRR settings. A little question. Why do we want to bind irq of eth0 to a single CPU ? imho it will casue slowdown of some situation. Why don't we leave scheduler to select CPU for processing IRQ ? - Gabor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
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 course the real memory should be cached in every CPU to avoid slowdowns. So that if you set that eth0's IRQ will be handled by CPU1, the MTRRs of CPU1 will be set accordingly, and the other CPUs will not care about eth0, so they do not need eth0's MTRR settings. A little question. Why do we want to bind irq of eth0 to a single CPU ? imho it will casue slowdown of some situation. Why don't we leave scheduler to select CPU for processing IRQ ? - Gabor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
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 settings. They also give pseudo-code for how to update them on an SMP system, which mtrr.c follows. If the BIOS has set them up differently at boot time, mtrr.c will complain and copy the MTRR settings of CPU0 to the others. Regards, David Wragg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
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 memory and the commonly accessed mmio register areas. The idea came because fiddling with MTRRs quickly revaled that only 8 variable ones exist. I see. I think there is a more straightforward solution: PAT does the same thing as MTRRs, but has no such "number of ranges" limitation --- it lets you set the memory type on a page-by-page basis. If the number of MTRRs becomes a problem (anyone know how many the P4 has?), then the real solution is to implement PAT support. IIRC, only the PPro, the first PII model (Klamath?), and the first Celeron model have MTRR but not PAT (Athlon has PAT, but /proc/cpuinfo misreports it as "fcmov", at least in 2.2.14; Xeons always had PAT). David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
