Messages in this thread | | | From | (Ramakrishna K) | Subject | Re: Address spaces on a i386 - Getting Confused (fwd) | Date | Wed, 31 Mar 1999 10:16:28 +0530 (IST) |
| |
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/
| |