Re: Prioritize my own app's disk access
Re: Prioritize my own app's disk access
- Subject: Re: Prioritize my own app's disk access
- From: Jonathan Taylor <email@hidden>
- Date: Tue, 05 Jul 2016 22:40:03 +0100
Thanks everyone for your replies on this second question of mine. Some responses below:
On 5 Jul 2016, at 18:20, Quincey Morris <email@hidden> wrote:
> What worries me about the Darwin-level (i.e. Unix-level) API suggestions that others have made is that you don’t know how these interact with Cocoa apps. You didn’t actually say whether your app is a Cocoa app, but if so …
It is indeed a cocoa app.
> I think the best modern approach is to route your CPU and IO usage via GCD. That is, from the point where some callback gives you raw video, use dispatch_async to schedule the processing on a GCD queue, and use the GCD I/O primitives to actually do the I/O.
> That will allow you to specify a quality of service (“user interactive” is the highest), which should interact properly with other apps, e.g. the Finder doing a large copy.
> That should take care of CPU and IO. For memory, I agree with Jens that you should preallocate and reuse memory buffers, rather than re-allocating them, as far as possible.
Interesting. I know and love GCD queues, but have not played with the I/O stuff. As far as the quality of service goes, I can't see the APIs for that (looking in the 10.9 SDK, at least). Am I looking in the wrong place? Text search for variants on "user interactive" haven't brought up anything for me in the "dispatch" folder.
If I am honest, I suspect I will probably leave things as-is - the for the same pragmatic reasons I mentioned in my other email. Unless and until I have problems with i/o throughput when my own app is running unmolested, I think I'll probably just reiterate advice to users not to leave large copy operations running in the background while also recording to disk! I thought I would ask the question just in case there was an easy solution I should know about, but it sounds as if (understandably) any solution would be fairly involved and require some structural changes to my code. That's not to say that it isn't very interesting to broaden my mind and understand better what APIs are out there, for the next time...
On 5 Jul 2016, at 17:19, Jens Alfke <email@hidden> wrote:
> In addition to increasing I/O priority, there may be other ways to make your disk writes more efficient. For example you can preallocate space for the file before writing to it. Writing in larger chunks may also help. (Of course you may have tried these already.)
I confess that currently I am using pure cocoa -writeToFile:atomically calls. I am fully aware that this is very unlikely to be the best way to do high performance IO, but it's great in terms of convenience. Again, I'm afraid (in the very specific context of a not-that-widely-distributed program running on dedicated computers) my question was fishing for a low-hanging fruit that might allow me a quick fix that left my own code as-is but encouraged the Finder to play nicely along with my not-entirely-optimal code :-)
> Using wired memory for your buffers is also a good idea, since if any of those buffers get paged out things will really go to hell.
Buffer paging is indeed what eventually brings the program (and machine) to its knees if things go *really* badly wrong in terms of a backlog. I'm not seeing how this would solve a fundamental problem of i/o bandwidth being inadequate, but I can see that this would be a good thing to do in terms of preventing some *transient* condition from tipping things from one stable state (streaming to disk successfully) to another stable, but disastrous, state (thrashing the disk due to paging, meaning the frames can't be saved fast enough, more backlog, more thrashing, etc).
> Also, I assume you’ve profiled the code and are confident that it’s being constrained by I/O bandwidth and not CPU time? (It’s possible that I/O requests made by real-time threads get higher priority; I can’t remember if this is the case, as it’s a long time since I’ve had to deal with this sort of stuff.)
Yes. Definitely measured as an i/o bandwidth issue in this case. I am presuming (though have not profiled on this level of detail) that the problem is primarily one of seek times on a magnetic disk - a Finder copy going on in the background is competing with my own writes in terms of where the disk head needs to be...
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden