I don’t think you’ll get a user address in system thread context, for
example, work item
On 1/29/09, Balint K wrote: >> There is simply no need to lock the pages in order to share them with user >> mode. If both user mode and your driver open the same section their mapped >> view of the section will be shared memory, pageable shared memory. > > I’ve been trying hard but still dindn’t manage to get a mapped view in > kernel address space without locking. ZwMapViewOfSection always > returns an user mode address (< 0x80000000) for me, even with > OBJ_KERNEL_HANDLE. How should I proceed? > >> Your original post asked what to about the driver’s need to lock this >> mapped >> view of the section in order to access it at raised IRQL. Your concern >> was > > Sorry for not being clear enough, but it’s the opposite: I’m sure that > the driver runs at PASSIVE_LEVEL, so I I want to fix it to avoid > locking. > >> It might be possible to only map portions of the region on an as needed > > I was thinking about this too as a last resort, but it would require a > major redesign of the driver. > > Thanks for the help > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
> That is the pbem with shared memory. By locking and remapping u just
bring extra overhead. And what is the pb with user address, Kernel
mode can address it fine. Obj_kernel_handle wont help you, it will
The problem is the overhead you mentioned. Because the section is
accessed from arbitrary context, I’d have to map and unmap it on each
invocation.
By the way what could be the reason behind the lack of an API for
mapping to system space without locking? I was thinking that the
memory manager would offer more opportunities to a driver.
> Map this to System process and access the memory by pointer from the system thread via __try/__except
Thanks for the suggestion, I will try this out.
How much performance overhead would the extra context switches mean?
Would the overhead be higher if mapping/unmapping at each IRP? (The
section needs to be accessed from IRP_MJ_CREATE and IRP_MJ_CREATE of a
fs filter driver.)
The create path is slow anyway. But you could probably benefit by adding a
caching scheme in front of this so that you only have to push things off to
a system worker thread on a cache miss.
Mark Roddy
On Fri, Jan 30, 2009 at 7:07 AM, Balint K wrote:
> > Map this to System process and access the memory by pointer from the > system thread via try/ except > > Thanks for the suggestion, I will try this out. > > How much performance overhead would the extra context switches mean? > Would the overhead be higher if mapping/unmapping at each IRP? (The > section needs to be accessed from IRP_MJ_CREATE and IRP_MJ_CREATE of a > fs filter driver.) > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Usually, mapping large amounts of address space in kernel mode is discouraged, especially for extended durations. s Kernel address space is very constrained on 32-bit systems, especially when one considers scenarios like users that boot /3GB, and soforth. In such cases, ~1GB must be enough for all kernel code + data.
? S
-----Original Message-----
From: Balint K Sent: Friday, January 30, 2009 03:35 To: Windows System Software Devs Interest List Subject: Re: [ntdev] sharing paged memory
> That is the pbem with shared memory. By locking and remapping u just > bring extra overhead. And what is the pb with user address, Kernel > mode can address it fine. Obj_kernel_handle wont help you, it will
The problem is the overhead you mentioned. Because the section is accessed from arbitrary context, I’d have to map and unmap it on each invocation.
By the way what could be the reason behind the lack of an API for mapping to system space without locking? I was thinking that the memory manager would offer more opportunities to a driver.