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

2000-10-12 Thread Boszormenyi Zoltan
On Thu, 12 Oct 2000, James Simmons wrote: > > > > 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. > > > >

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

2000-10-12 Thread James Simmons
> > 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

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

2000-10-12 Thread Boszormenyi Zoltan
On 12 Oct 2000, David Wragg wrote: > 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 manual

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

2000-10-12 Thread Boszormenyi Zoltan
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 th