------_=_NextPart_001_01BE7F6E.3B1D0260
Content-Type: text/plain;
charset="iso-8859-1"
> I haven't seen much interest from people wanting >4G support on other
> 32-bit architectures, and on 64-bit platforms it's a different game
> altogether.
Agreed. From what we've seen, most PCI devices running on 64-bit systems
are already going 64-bit.
The problem of 32 bits on >4GB will probably be isolated to Intel. Why
would someone put an older, $50 board in a $10k workstation anyway?
> Don't worry, I'm well aware of this: I've already started specing out
> support for 64G physical memory on Intel. _Right now_, the
> only special
> case we support is ISA dma. For the future, we will need something a
> lot more powerful, but that is planned anyway.
As for this, here's another idea. Instead of locking user buffers, another
possibility would be to allocate with GFP_DMAPCI or similar to get suitable
DMA'able kernel space memory (e.g. under 4GB). We agree this is already
needed for when the kernel wants kernel memory for a device. Then, a
standard syscall (e.g. my proposed dmamalloc()) could be used to map this
memory into userland. The main things I'm looking for here are:
1) Know the memory will not be physically relocated or swapped to disk
during I/O (inherently so if we get_free_page(GFP_anything) or vmalloc() the
memory);
2) Be able to build a scatter/gather DMA length/address list in a _standard_
fashion at kernel level, without requiring the driver to do it except by a
single call;
3) Provide that this memory gets freed if the last process using it is
killed.
I keep hearing cries like 'use mmap' and 'use mmap' :-) but I have a
definite reason NOT to use mmap() for this. What if a device wants to use
mmap() for PIO access, and provide direct DMA as well, such as a mirrored
memory card? I don't see a non-hackish mechanism for differentiating
between the two distinctly different accesses. And my whole point is to do
this in the _right_ way. Number two comes from the same school of thought.
Requiring any driver to deal with page tables at all is a hack, IMHO.
-- Eric Lowe elowe@systran.com Software Engineer Co-op, Systran Corporation 937-252-5601 x330 ((my apologies for any HTML attached, my e-mail gateway is adding it and I can't disable it))------_=_NextPart_001_01BE7F6E.3B1D0260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: Address spaces on a i386 - Getting Confused
> I haven't seen much interest from people wanting = >4G support on other
> 32-bit architectures, and on 64-bit platforms = it's a different game
> altogether.Agreed. From what we've seen, most PCI devices = running on 64-bit systems are already going 64-bit.
The problem of 32 bits on >4GB will probably be = isolated to Intel. Why would someone put an older, $50 board in a = $10k workstation anyway?> Don't worry, I'm well aware of this: I've = already started specing out
> support for 64G physical memory on Intel. = _Right now_, the
> only special
> case we support is ISA dma. For the = future, we will need something a
> lot more powerful, but that is planned = anyway.As for this, here's another idea. Instead of = locking user buffers, another possibility would be to allocate with = GFP_DMAPCI or similar to get suitable DMA'able kernel space memory = (e.g. under 4GB). We agree this is already needed for when the = kernel wants kernel memory for a device. Then, a standard syscall = (e.g. my proposed dmamalloc()) could be used to map this memory into = userland. The main things I'm looking for here are:
1) Know the memory will not be physically relocated = or swapped to disk during I/O (inherently so if we = get_free_page(GFP_anything) or vmalloc() the memory);
2) Be able to build a scatter/gather DMA = length/address list in a _standard_ fashion at kernel level, without = requiring the driver to do it except by a single call;
3) Provide that this memory gets freed if the last = process using it is killed.
I keep hearing cries like 'use mmap' and 'use mmap' = :-) but I have a definite reason NOT to use mmap() for this. What = if a device wants to use mmap() for PIO access, and provide direct DMA = as well, such as a mirrored memory card? I don't see a = non-hackish mechanism for differentiating between the two distinctly = different accesses. And my whole point is to do this in the = _right_ way. Number two comes from the same school of = thought. Requiring any driver to deal with page tables at all is = a hack, IMHO.
--
------_=_NextPart_001_01BE7F6E.3B1D0260--
Eric Lowe
elowe@systran.com
Software Engineer Co-op, Systran Corporation
937-252-5601 x330
((my apologies for any HTML attached, my e-mail = gateway is adding it and I can't disable it))- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/