This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11167 - Add IO priorities, and lower the priority of the dircache thread
Attached to Project:
Rockbox
Opened by Frank Gevaerts (fg) - Thursday, 01 April 2010, 23:35 GMT+2
Last edited by Frank Gevaerts (fg) - Sunday, 04 April 2010, 00:02 GMT+2
Opened by Frank Gevaerts (fg) - Thursday, 01 April 2010, 23:35 GMT+2
Last edited by Frank Gevaerts (fg) - Sunday, 04 April 2010, 00:02 GMT+2
|
DetailsThis patch adds a storage_is_busy_elsewhere() function that returns true if another thread has recently (HZ/10 right now) accessed the disk. This is then used in the dircache thread to sleep a bit in such cases, so user-visible disk accesses like buffering or loading the wps get absolute priority. This improves boot times to the root menu from 11.4 seconds to 1.5 seconds, with playback then immediately starting.
The current code is still mostly a proof of concept, with things only implemented for ATA (ir probably won't even compile for others), and storage_* integration isn't done properly. It should be perfectly safe though. |
This task depends upon
Closed by Frank Gevaerts (fg)
Sunday, 04 April 2010, 00:02 GMT+2
Reason for closing: Accepted
Additional comments about closing: r25459
Sunday, 04 April 2010, 00:02 GMT+2
Reason for closing: Accepted
Additional comments about closing: r25459
Regarding the storage_* integration, I find it really akward but I'm not sure there is a proper way to do such a thing (except giving the threads an explicit I/O priority ?).
And finally, does such a modification makes sense on flash-based (ie non-hard drive) storage ?
I think it probably makes sense on flash as well. The numbers will of course be vastly different, but the dircache thread will still slow things down a bit by using bandwidth while things like buffering are going on. We'll see.
I've made storage_is_busy_elsewhere() (and the corresponding code elsewhere) dependent on HAVE_DIRCACHE. It might be better to give it its own CONFIG_* define
There's a RAM delta of around 32 bytes for targets without dircache, and from 200 to 300 bytes for targets with dircache.
There are still a few possible questions:
- Are the times I picked good enough? (STORAGE_MINIMUM_IDLE_TIME and STORAGE_DELAY_UNIT in storage.c)
- Do we want this only for disk targets, or also for flash? I think it can't hurt flash, so I'd do it everywhere. (the current patch enables it for all targets that have dircache)
- Currently the waiting loop checks with the same priority for each iteration. The alternative would be to slowly raise the priority (thereby eliminating one variable). As long as we only use two priorities this won't make a difference. Which should we pick?
The changes in disk.c, fat.c, and usb_storage.c are only half related, and are due to the change from macros to wrapper functions.
In theory this could slow down things on multidrive systems, but I doubt if it's ever going to be a problem in practice