On Thu, May 02, 2002 at 09:10:00AM -0700, Martin J. Bligh wrote:
>> Even with 64 bit DMA, the real problem is breaking the assumption
>> that mem between 0 and 896Mb phys maps 1-1 onto kernel space.
>> That's 90% of the difficulty of what Dan's doing anyway, as I
>> see it.
On Thu, May 02, 2002 at 06:40:37PM +0200, Andrea Arcangeli wrote:
> control on virt_to_page, pci_map_single, __va. Actually it may be as
> well cleaner to just let the arch define page_address() when
> discontigmem is enabled (instead of hacking on top of __va), that's a
> few liner. (the only true limit you have is on the phys ram above 4G,
> that cannot definitely go into zone-normal regardless if it belongs to a
> direct mapping or not because of pci32 API)
Being unable to have any ZONE_NORMAL above 4GB allows no change at all.
32-bit PCI is not used on NUMA-Q AFAIK.
So long as zones are physically contiguous and __va() does what its
name implies, page_address() should operate properly aside from the
sizeof(phys_addr) > sizeof(unsigned long) overflow issue (which I
believe was recently resolved; if not I will do so myself shortly).
With SGI's discontigmem, one would need an UNMAP_NR_DENSE() as the
position in mem_map array does not describe the offset into the region
of physical memory occupied by the zone. UNMAP_NR_DENSE() may be
expensive enough architectures using MAP_NR_DENSE() may be better off
using ARCH_WANT_VIRTUAL, as page_address() is a common operation. If
space conservation is as important a consideration for stability as it
is on architectures with severely limited kernel virtual address spaces,
it may be preferable to implement such despite the computational expense.
iSeries will likely have physically discontiguous zones and so it won't
be able to use an address calculation based page_address() either.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:14 EST