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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.