Re: [Linux-ia64] BitKeeper tree for 2.4.x

From: Steffen Persvold <>
Date: 2002-10-18 04:31:22
On Thu, 17 Oct 2002, Bjorn Helgaas wrote:

> > Which IA64 hardware doesn't support _PAGE_MA_WC in the PTE ? My IA64 docs 
> > doesn't mention anything about that.
> The *processors* all support WC, no problem there.  The problem is
> that the *chipset* may not.  The EFI memory descriptor table (from
> GetMemoryMap()) tells us which attributes are supported for each
> region of address space.
> According to the EFI shell "memmap" command, the i2000 (BigSur)
> supports WB or UC for memory, and UC for MMIO space.  No
> mention of WC, so we have to assume it's not supported.
> HP ZX1 machines report that they support WB for memory and
> UC for MMIO space.  The ZX1 chipset is supposed to support WC
> for MMIO space, so the fact that EFI doesn't report that looks
> like a firmware defect.

So what does "supported" by the chipset actually mean ? I've tested the 
SCI cards in both BigSurs and ZX2000 and it works fine on IO memory 
(roughly 330 MByte on both platforms).

I was in under the impression that WC can be implemented in different 
sections of the system (processor->memorycontroller, 
memorycontroller->pci etc), and that the section we control with the 
WC attribute in the PTE is transactions on the 
processor->memorycontroller bus (as it is on the IA32 systems with MTRRs). 
Then the question of wether the memory contoller (chipset) is able to 
support large bursts of data on the processor->memorycontroller bus comes 
down to buffer space in the memory controller, and I can't really imagine 
that this isn't large enough (haven't checked though).

_But_ I agree that if the firmware has the ability to report this (and 
we can trust the information) we should take advantage of it (sort of the 
same thing which is done when someone tries to create a WC memory region 
on IA32, not all processors supports this).

> > Actually I think _PAGE_MA_WC is only applicable to IO memory the same way 
> > as _PAGE_MA_UC is. Can't it be handled in the same way ? (you've already 
> > done the fix for UC, right ?)
> WC could be used for memory as well as for MMIO space -- an
> example is for AGP, where drivers like to have main memory
> buffers mapped with WC, and the AGP engine can do non-coherent
> DMA from the buffers.  That doesn't work on IA64 because we
> use large TLB pages to map all of main memory with the WB
> attribute, and there's no easy way to support WC mappings
> at the same time.

I can't really see why mapping main memory with WC (processor) should 
affect the DMA performance of the AGP card. The other way around (mapping 
the AGP card's memory with WC) makes sense though and I know a lot of 
drivers that does this.

> The mmap support for UC currently cheats a little bit.  We
> don't look at the EFI tables; we just use UC whenever we mmap
> something that isn't main memory (this is in mmap_mem(), BTW).

Some time ago I submitted a patch do David to allow mapping IO pages with 
WC in kernel space (ioremap()). Back then I remember this discussion about 
multiple processes having different PTE attributes on the same pages, so I 
guess this stuff with PTE attributes should be cleaned up (for all archs 

  Steffen Persvold   | Scalable Linux Systems |   Try out the world's best |  | performing MPI implementation:
Tel: (+47) 2262 8950 |   Olaf Helsets vei 6   |      - ScaMPI 1.13.8 -
Fax: (+47) 2262 8951 |   N0621 Oslo, NORWAY   | >320MBytes/s and <4uS latency
Received on Thu Oct 17 11:31:41 2002

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:10 EST