Re: What should we do when headers are missing in 10.2?
Re: What should we do when headers are missing in 10.2?
- Subject: Re: What should we do when headers are missing in 10.2?
- From: Jim Magee <email@hidden>
- Date: Wed, 11 Sep 2002 15:49:15 -0400
On Wednesday, September 11, 2002, at 01:35 PM, Andrew Gallatin wrote:
Jim Magee writes:
Doing what you ask would require "prepare" to create and hold its own
reference to the underlying memory objects rather than "glom-ing" on
to
the user's reference (leaving the user free to release his own with
impunity). This could be done, but it would slow prepare down even
more in its current form (and it is in dire need of a performance
boost
already). In fact, we are in the process of investigating possible
enhancements to the implementation. The leading design does involve
burrowing all the way down to the object, so we do have the
opportunity
to think about taking our own references again. This would allow
unprepare to be much more efficient, and subsequent prepares in the
same object could also be quicker. But is also allows a possible
redress of your issue.
Excellent!
Also, memory locking on MacOSX is currently slower than on any other
unix-like platform we support. It would be good to see it sped up.
The "speed up" thing is an almost certainty. I think that goes
hand-in-hand with the deallocate fix as well. But I can't promise that
at this point (I'm not doing the code). But I will continue to push
for it - and it sounds promising.
The real question is: Does anything depend upon that portion of the
address space being locked down while I/O is in progress? It would be
difficult to see how they could, because the prepare gets released
before their notion of an I/O operation is marked as complete. But
it's just something to investigate.
Nothing depends on that part of the address space being locked down.
I didn't really mean in your specific case. I meant in general, since
this is a general API.
However, the physical memory (formerly) backing the portion of the
apps virtual address space which it has just freed cannot be recycled.
Otherwise we risk either corrupting memory if those pages end up
belonging to some other task. Ideally, the memory would be removed
from the app's address space when it called free(), and the physical
pages would held in limbo, only freed back to the system when we
unprepared it and some reference count dropped to zero.
Of course.
PS: I think, last we left it, we also talked about changing the timing
between file-descriptor closing and VM cleaning. We intentionally
clean up the Mach port space (which IOKit UserClient interfaces
typically use) before the VM space so that UserClient memory
descriptors would be freed before attempting to free the memory in an
exiting process. Closing file descriptors should happen even before
that (to allow file-descriptor-based drivers to release their holds on
memory). While this may not be necessary, if we do the work above, it
is still the cleaner way to go.
This like what I was asking for... Has the behaviour changed? I
haven't looked into this since I wrote my reaper thread work around,
which uses APPLE_API_PRIVATE apis.
No it still closes file descriptors AFTER the memory deallocation
[attempt]. But I am working on a proposal with a couple of the other
kernel engineers as we speak.
Radars from the outside world (developers) are always good to help
justify these changes. I would appreciate it if you could write a
couple up for the two issues discussed here.
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.