[lkml]   [2000]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
Boszormenyi Zoltan <> 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).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.060 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site