Path: news.mitre.org!blanket.mitre.org!philabs!newsjunkie.ans.net!newsfeeds.ans.net!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!usc!newshub.cts.com!newsfeed.cts.com!cmkrnl!jeh From: jeh@cmkrnl.com (Jamie Hanrahan) Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode Subject: Re: Accessing user-buffers in dispatch routine at DISPATCH_LEVEL Message-ID: <1998Jan2.103356.8381@cmkrnl> Date: 2 Jan 98 10:33:56 PST References: <34A8C0DD.682FD2DC@nomail.com> <1997Dec30.092820.8377@cmkrnl> <34ACADE1.6D1016@nomail.com> Organization: Kernel Mode Systems, San Diego, CA Lines: 80 In article <34ACADE1.6D1016@nomail.com>, "L.P" writes: > Sorry, I forgot to mention that the ioctl parameter block is in fact a > vector of data pointers in user-space. This is to optimize the data > transfer by allowing multiple data messages to be sent through only one > ioctl issued. I will then use METHOD_BUFFERED for the parameter block > and will need to probe-and-lock process-space data buffers. Arrggh... try doing it the easy way first. Only after you've proven that you *need* to reduce the overhead should you invent schemes like this. >> b. It is safer to NOT use the process-space virtual address, as it >> could be unmapped (VirtualFree) by the process at any time (even >> though you're still holding the MDL). > > b.1) One precision : Beside the MDL, if the driver also holds the IRP > during copy time in the dispatch routine (thread-context) AND the > application does not use the overlap feature, doesn't this ensure that > the process-space virtual addresses will not be unmapped during the IRP > processing ?. No, since another thread in the process could do the VirtualUnlock. >>> > 3. I could get a system-space address for the locked user-buffer >>> but I >>> > read (in the Art Baker book) that this is not advisable as ALL >>> caches >>> > from ALL processors are flushed when unlocking the memory. >> >> I'm not aware of this and can't find any evidence of it. > > In his book, at page 262 there is a footnote referring to the > 'MappedSystemVa' field of the MDL and this footnote says (dixit the > book) : < the buffer can cause a great deal of system overhead.>>. I don't know > what he exactly means here. > Should we consider his point irrelevant and therefore log another 'book > error' ?. My tests involving throughput through a null device driver that does MmGetSystemAddressForMdl indicate that he's mistaken. The overhead appears to be a small fraction of the total I/O time. >> But whether it's true or not, you're doing the same thing by calling >> MmMapLockedPages, as MmGetSystemAddressForMdl is just a macro around >> MmMapLockedPages. > > I did not know these two were related. I am trying to get away with > remaping the process-space virtual addresses in system-space because the > user-buffers passed to the driver have a very short lifespan (consumed > in the dispatch routine) and this path being the data path it is > critically important to minimize the overhead on data processing.If I > use MmGSAFMdl (or MmMapLockedPages), this will flush the cache when > unmapping the system-space address (correct me if I'm wrong here) and > the cache will be flushed again when the application will free the > user-buffers memory (correct me if I'm wrong here). I don't see why the cpu/memory caches should be flushed due to the creation or destruction of virtual address space, whether process or system space. Caches are managed in terms of physical addresses and the fact that a page table entry either does or does not reference a given physical page does not seem to me to have any ramifications for the cache. There *are* some translation buffer issues, but as I said, you have to pay that price anyway, for system or process-space mapping, so you might as well stick as close as possible to standard mechanisms. Also, why would the application "free the user buffer memory"? A free(), popping the stack, etc., does not unmap the virtual address space of the buffer. The heap is virtually expanded on demand but is never virtually unmapped unless you ask for that explicitly. Similarly, the user mode stacks are committed on demand but are never decommitted until thread rundown. --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA Internet: jeh@cmkrnl.com (JH645) CompuServe: 74140,2055 drivers, internals, networks, applications, and training for VMS and Windows NT NT driver FAQ, links, and other information: http://www.cmkrnl.com/ If you post a reply in news, please don't e-mail it too.