Re: Shared memory between kernel driver and multiple processes
- From: "Olivier M" <olivier_martin@xxxxxxxxxxx>
- Date: 16 Nov 2006 09:34:49 -0800
From: voidcoder wrote :
In case you are talking about CE 6.0 (otherwise I can't explain what VM routines like
VirtualAllocCopyEx() do in your solutions
1 and 2), you don't have too much choice here. Either allocate physically contiguous
region in your kmode driver and map it to the process, or use file mapping to map
physically discontinuous virtual memory.
- To clarify, we are talking about WinCE6.0
From: Dean Ramsier wrote :
I guess I don't see why you are concerned about physically contiguous
memory.
- Don't want to use physically contiguous memory as this is only
guaranteed to be available at boot-time
AFAIK, VirtualAllocCopyEx() doesn't have to be used with physical
memory addresses. It operates generically on virtual memory. That virtual
memory, when committed, will be backed by physical memory. Might not be
contiguous but you don't care. Its ability to map in specific physical
addresses is a special case.
The bigger issue I think will be keeping the memory coherent. You'll have
to be careful to make sure your different processes are properly
synchronized with the backing memory. That won't be easy if you have a
virtually tagged cache such as exists on the ARM cpus unless you map in the
memory as uncached.
- The memory I'm referring to is uncached since it is addressable by
a device in the system other than the CPU.
Memory mapped files are created just for this scenario (sharing data buffers
between multiple processes) and will handle the data coherency for you.
- Assuming the memory is uncached then coherency is not an issue. Do
Memory Mapped Files only allow one view to be open at a time?
e.g. have 2 process which both need concurrent access (sequencing the
cross process accesses is handled using other mechanisms)
From: Sue Loh [MS] wrote :
It sounds like memory mapped files are exactly what you need here. One best
practice I'd attach to that recommendation is, don't pass pointers around
between processes. (Don't store pointers inside the memory-mapped file
either.) Instead use offsets. That way, if the view is loaded at different
addresses in different processes, your code will still work.
- Is there an inherent overhead in creating Memory mapped files?
It's possible we could be creating a lot to describe discrete kernel
driver allocations that need to be mapped to arbitrary processes
To add to what Dean said -- VirtualAllocCopyEx can copy from virtual
addresses. And VirtualAllocCopyEx (unlike VirtualCopy[Ex]) will take care
of cache coherency for you. On virtually tagged ARM CPUs it will cause the
source and destination of the copy to be uncached until the copy is freed.
That prevents cache coherency problems, but it could lead to performance
problems if your program is really sensitive to memory access speed.
[Underneath the covers, memory mapped files will do the same thing actually]
In general, I would say VirtualAllocCopyEx is not something to use unless it
is clearly your only option.
- Going back to the original post, is there any reason why a kernel
driver allocation made via HeapCreate/Alloc cannot be remapped to the
calling process via VirtualAllocCopyEx?
- VirtualAllocEx is what I would choose to use but it doesn't provide
a single consistent kernel cpu virtual address rather a user address
that's only valid in the kernel when called by the context that
created it. I understand that memory mapped files are a solution but
it seems unnecessary for the user-mode code to have to open a memory
mapped file view if the kernel driver can do it all on behalf of the
calling process.
Thanks Again
.
- Follow-Ups:
- Re: Shared memory between kernel driver and multiple processes
- From: voidcoder
- Re: Shared memory between kernel driver and multiple processes
- From: Sue Loh [MS]
- Re: Shared memory between kernel driver and multiple processes
- From: Dean Ramsier
- Re: Shared memory between kernel driver and multiple processes
- References:
- Shared memory between kernel driver and multiple processes
- From: Olivier M
- Re: Shared memory between kernel driver and multiple processes
- From: voidcoder
- Re: Shared memory between kernel driver and multiple processes
- From: Dean Ramsier
- Re: Shared memory between kernel driver and multiple processes
- From: Sue Loh [MS]
- Shared memory between kernel driver and multiple processes
- Prev by Date: Re: Fsdspy driver on PocketPC
- Next by Date: Re: How to get USB / Ethernet (NIC) working on MS Windows CE 5.0 ?
- Previous by thread: Re: Shared memory between kernel driver and multiple processes
- Next by thread: Re: Shared memory between kernel driver and multiple processes
- Index(es):
Relevant Pages
|