Rockbox

Tasklist

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, 21:35 GMT
Last edited by Frank Gevaerts (fg) - Saturday, 03 April 2010, 22:02 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This 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)
Saturday, 03 April 2010, 22:02 GMT
Reason for closing:  Accepted
Additional comments about closing:  r25459
Comment by amaury pouly (pamaury) - Friday, 02 April 2010, 08:00 GMT
From the dircache point of view, the modification is trivial and makes sense so I agree with the idea. My only point is that it will slow down the update process in background and is more likely to trigger et know bug that Slasheri told me would fix but he never did (I promise one day I'll fix it :)).
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 ?
Comment by Frank Gevaerts (fg) - Friday, 02 April 2010, 08:37 GMT
The storage_* integration is indeed awkward. It was designed to be implemented quickly so I could test, not to be an example of clean code (which is what I meant by "mostly a proof of concept")

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.
Comment by Frank Gevaerts (fg) - Friday, 02 April 2010, 17:02 GMT
An attempt at doing this in a cleanly integrated way, for all storage types. This one uses a wrapper function for storage_(read|write)_sectors(), which means that the IF_MD2() stuff is back for all users of those.
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.
Comment by Frank Gevaerts (fg) - Saturday, 03 April 2010, 13:45 GMT
This patch reworks the entire thing to a more generic io priority concept. I think it's about OK for commit now

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.
Comment by Frank Gevaerts (fg) - Saturday, 03 April 2010, 13:49 GMT
Oh, one more thing that would be nice to have is to differentiate between drives on multi-drive systems. Currently I don't do this because the drivers don't give enough information (*_last_disk_activity() doesn't take a drive argument)

In theory this could slow down things on multidrive systems, but I doubt if it's ever going to be a problem in practice
Comment by Frank Gevaerts (fg) - Saturday, 03 April 2010, 14:13 GMT
This one should also handle multiple drives properly.
Comment by Frank Gevaerts (fg) - Saturday, 03 April 2010, 14:23 GMT
Fix stupid warning.

Loading...