lkml.org 
[lkml]   [1999]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Address spaces on a i386 - Getting Confused (fwd)
Date
Forwarded message:
>
> Eric,
>
> > But there are various other horrible problems. If it were that easy, I'm
> > sure the kernel would have supported it long ago.
> >
> > 1) What to do if the process is killed while the pages are locked?
> If the process is killed, the exit code for the process will release the page
> mappings for the page behind its user-virtual address.
>
> If the structure for a page has a count of the number of users/accessors to it
> who have it mapped, then the count should be 2. One for the mapping from the
> user-area and another one from the kernel.
>
> Now coming to the following scenarios :
> 1. If user process is killed, when the kernel mapping is in place.
>
> The unmapping part of kernel virtual address in the kernel should release the
> page as also the locking. ( It can make out it's the only accessor ).
>
> 2. If at the time of process getting killed, only the user-mapping exists, then
> again the VM code should take care of it. I assume it does work this way right now.
> Ex: If a process has some pages locked and the process is killed, the pages am
> sure are unlocked and released to the free pool.
>
> > 2) What if you have multiple threads trying to access the buffer
> > simultaneously, or, worse yet, you're using asynchronous DMA reads and
> > writes?
> This is more of a threads programming problem at the user-level. The threads need to
> synchronize their access to this piece of data using some mechanism. Or am i missing
> something here.
>
> Even in case of async operations, assume the case of a read.
> We issue a read, and then proceed further in the thread without waiting for the
> operation to be over. In this case the execution path in the thread will not and
> should not do anything relating to this data that will be received, till it gets
> a notification for the completion of the DMA.
>
> > 3) What if multiple DMAs are trying to access the same buffer? Who should
> > win?
> When we get a physical address for DMA'ing, don't we ensure that only one DMA
> happens at a time. If multiple DMA's happen to the same address, then we'll end
> up getting data which is of no use to us. Though i have a related doubt here,
> can/does the system/DMA hardware support multiple DMA's happening to the same
> address ? Sorry for my ignorance on this.
>
> Stephen,
> May be you would like to comment on any issues missed out here ?
>
> thanks,
> Rama.
> >
> > I'm writing more robust code for character and streaming drivers that
> > attempts to address these issues. Stephen Tweedie (sct@redhat.com) has some
> > patches already available that will do direct I/O by wrapping block drivers.
> > His code is at ftp://ftp.linux.org.uk/pub/linux/sct/fs/raw-xxxxxxxx.tar.gz.
> >
> > --
> > Eric Lowe
> > elowe@systran.com
> > Software Engineer Co-op, Systran Corporation
> > 937-252-5601 x330
> > (( my apologies for the HTML attached, my stupid e-mail gateway is doing it,
> > I can't stop it.. ))
> >
> > >
> > > I am not familiar with Linux code.
> > >
> > > But a solution to DMA'ing to user-space will be
> > > a) lock the relevant user range into memory.
> > > b) touch them to fault the pages in.
> > > c) Then trap into the kernel using an ioctl to set up
> > > kernel address for this
> > > range. ( I bet there must be some VM calls to acheive
> > > that ). What i mean
> > > is that get the pages behind the locked user-address
> > > behind the kernel address.
> > > d) Do the DMA to these pages.
> > > e) Release the kernel-mappings.
> > >
> > > This helps in zero-copy DMA. Also the user-pages are still
> > > swappable, once the DMA is
> > > done and after they are unlocked.
> > >
> >
>


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.023 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site