Messages in this thread | | | From | Eric Lowe <> | Subject | RE: Address spaces on a i386 - Getting Confused | Date | Mon, 5 Apr 1999 10:11:42 -0400 |
| |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0"> <TITLE>RE: Address spaces on a i386 - Getting Confused</TITLE> </HEAD> <BODY> <BR>
<P><FONT SIZE=2>> I haven't seen much interest from people wanting >4G support on other</FONT> <BR><FONT SIZE=2>> 32-bit architectures, and on 64-bit platforms it's a different game</FONT> <BR><FONT SIZE=2>> altogether. </FONT> </P>
<P><FONT SIZE=2>Agreed. From what we've seen, most PCI devices running on 64-bit systems are already going 64-bit.</FONT> <BR><FONT SIZE=2>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?</FONT></P>
<P><FONT SIZE=2>> Don't worry, I'm well aware of this: I've already started specing out</FONT> <BR><FONT SIZE=2>> support for 64G physical memory on Intel. _Right now_, the </FONT> <BR><FONT SIZE=2>> only special</FONT> <BR><FONT SIZE=2>> case we support is ISA dma. For the future, we will need something a</FONT> <BR><FONT SIZE=2>> lot more powerful, but that is planned anyway.</FONT> </P>
<P><FONT SIZE=2>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:</FONT></P>
<P><FONT SIZE=2>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);</FONT></P>
<P><FONT SIZE=2>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;</FONT></P>
<P><FONT SIZE=2>3) Provide that this memory gets freed if the last process using it is killed.</FONT> </P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>--</FONT> <BR><FONT SIZE=2>Eric Lowe</FONT> <BR><FONT SIZE=2>elowe@systran.com</FONT> <BR><FONT SIZE=2>Software Engineer Co-op, Systran Corporation</FONT> <BR><FONT SIZE=2>937-252-5601 x330</FONT> <BR><FONT SIZE=2>((my apologies for any HTML attached, my e-mail gateway is adding it and I can't disable it))</FONT> </P>
</BODY> </HTML> | |