Re: Understanding Memory Descriptors
Re: Understanding Memory Descriptors
- Subject: Re: Understanding Memory Descriptors
- From: Duane Murphy <email@hidden>
- Date: Mon, 09 Nov 2009 11:53:04 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Nov 9, 2009, at 11:26 AM, Michael Smith wrote:
>
> On Nov 9, 2009, at 10:50 AM, Duane Murphy wrote:
>
>> I'm wondering if there is a way to "recover" an equivalent memory
>> descriptor from a memory descriptors virtual address.
>
> You're stuck in "I have no handle" hell.
>
Nice. :-)
>> Here's more detail.
>>
>> We use a user client interface to pass a large buffer to the kernel
>> to
>> read some data. This buffer is allocated in user space and passed
>> into
>> the user client to become the structureOutputDescriptor of the
>> IOExternalMethodArguments.
>>
>> Due to our cross platform interface, this buffer is converted to a
>> memory address and length using. The memory address is determined
>> using IOMemoryDescriotor::map() and getVirtualAddress() on the
>> resulting IOMemoryMap.
>
> Long term, you need to fix your "cross platform interface" so that
> it takes a handle, not a pointer/length tuple.
>
> The mapping operation you are performing here is *expensive* on
> every platform that splits the user/kernel virtual space, and it's
> never going to be cheap.
>
>> Later this self same address must be used to read data from the disk.
>> This is accomplished using IOMemoryDescriptor::withAddress() using
>> the
>> virtual address determined previously.
>>
>> Would this second memory descriptor be fundamentally equivalent to
>> the
>> first?
>
> Inasmuch as it describes the same range of client memory, yes.
>
>> Using the same addresses etc? Is there a way of making that
>> happen? My fear is that this process is contributing to virtual
>> memory
>> fragmentation or at least not making the best use of available
>> virtual
>> memory.
>
> You're definitely contributing to fragementation of the kernel's
> virtual address space when you map the original descriptor, and
> doing a lot of redundant work to construct the second descriptor.
>
The fragmentation of memory with respect to the original request from
user space seems unavoidable. Data has to be moved from the kernel
into user space somehow. Is there a better way to do this operation?
My concern is that constructing the second memory descriptor was also
contributing to the fragmentation.
>> The proper solution would, of course, be to be able to get the
>> original memory descriptor to the IO routine. Unfortunately that may
>> prove to be rather difficult given our cross platform engine.
>
> Does your "cross platform" code depend on dereferencing the pointer
> it's passed to manipulate data inside the buffer?
>
> If not, then consider passing a pointer to the IOMemoryDescriptor
> rather than the buffer.
>
> If it does, a common workaround is to maintain a list of currently-
> active IOMemoryDescriptors on the client side, and to look back into
> the list from your I/O shim to recover the IOMD. This doesn't save
> you the cost of mapping the descriptor, but it does save you
> constructing a second one. This lookup isn't necessarily as hard as
> it seems; your client can find the I/O shim fairly easy when it's
> instantiated, so it's just a matter of registering/deregistering its
> list as it comes and goes...
Indeed the addresses of the buffers are typically required. Thank you
for the suggestion, this may prove to be a viable solution, at least
in the short term.
...Duane
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.10.0 (Build 500)
Charset: US-ASCII
wsBVAwUBSvhzKUrg9acQ4r2CAQh/GAf+K9l9pVtzx6J7ipLXJoPVbXs8L09ctm0j
O0zdmDMLxQlOblsDML896mfORKRzzVcBZGibLXK8PzXTZBJSmrIIQDqqQ9kptP7J
CGmbBBPuQpZl22nzPz1PZ7TR0I2yLn73GIZGNEGc5XgMNN/QPks5CsUlsYPfIERx
GxE8dX8WRs0f5zUWYdedv5SWFcI1OBTn4xzBIMSvYDlJpfd95BV85lvnsQHDztIy
FrxiYiIq8qkhFqmtr7I3J/8lIFMm5M54mDNZjxLmghr8yUp5QwVHlCdmU1PYwjXA
JX6TlBMUKRMgbqmcO4N+S/qEJy+cMgeP1cVJsVSJfwFwie/1u/XK6A==
=wAlu
-----END PGP SIGNATURE-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden