lkml.org 
[lkml]   [1999]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Address spaces on a i386 - Getting Confused
Date
<!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>&gt; I haven't seen much interest from people wanting &gt;4G support on other</FONT>
<BR><FONT SIZE=2>&gt; 32-bit architectures, and on 64-bit platforms it's a different game</FONT>
<BR><FONT SIZE=2>&gt; altogether. </FONT>
</P>

<P><FONT SIZE=2>Agreed.&nbsp; 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 &gt;4GB will probably be isolated to Intel.&nbsp; Why would someone put an older, $50 board in a $10k workstation anyway?</FONT></P>

<P><FONT SIZE=2>&gt; Don't worry, I'm well aware of this: I've already started specing out</FONT>
<BR><FONT SIZE=2>&gt; support for 64G physical memory on Intel.&nbsp; _Right now_, the </FONT>
<BR><FONT SIZE=2>&gt; only special</FONT>
<BR><FONT SIZE=2>&gt; case we support is ISA dma.&nbsp; For the future, we will need something a</FONT>
<BR><FONT SIZE=2>&gt; lot more powerful, but that is planned anyway.</FONT>
</P>

<P><FONT SIZE=2>As for this, here's another idea.&nbsp; 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).&nbsp; We agree this is already needed for when the kernel wants kernel memory for a device.&nbsp; Then, a standard syscall (e.g. my proposed dmamalloc()) could be used to map this memory into userland.&nbsp; 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.&nbsp; What if a device wants to use mmap() for PIO access, and provide direct DMA as well, such as a mirrored memory card?&nbsp; I don't see a non-hackish mechanism for differentiating between the two distinctly different accesses.&nbsp; And my whole point is to do this in the _right_ way.&nbsp; Number two comes from the same school of thought.&nbsp; 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>
\
 
 \ /
  Last update: 2005-03-22 13:51    [W:1.154 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site