: > I think the principle of least surprise would suggest that it should : > work exactly like nice, rather than flip it around
: nice is actually intuitive - the higher the number, the 'nicer' the : processes are to the rest of the system.. : [...] : it's just *system* relative - not process relative.. Right now this is the least of my concerns. If someone wants to use dsched right now, he should know that he's using something experimental and hence should read up on whatever documentation is available, including the nice level inversion. Eventually I might change it to be similar to the normal nice levels, but it also would be only in one direction (i.e. -10 to 0, not -20 to 20). -- On another note, I really want to emphasize the fact that if you want to try dsched, don't use the patch that was attached to the first email, pull from my iosched-current branch on leaf which is up to date. I've done quite a few improvements since the original patch, mainly: - changing the algorithm to estimate the disk usage percent. Now it's done right, by measuring the time the disk spends idle in one balancing period. (thanks to corecode for the idea) - due to the previous change, I have also been able to add a feedback mechanism that tries to dispatch more requests if the disk becomes idle, even if all processes have already reached their rate limit by increasing the limit if needed. - moving the heavier balancing calculations out of the fq_balance thread and into the context of the processes/threads that do I/O, as far as this is possible. Some of the heavy balancing calculations will still occur in the dispatch thread instead of the issuing context. (thanks to Aggelos for the idea) - ironing out a few bugs related to int32_t overflow. - general cleanup & refactoring -- I also forgot to mention in my original email that there are some other interesting tools/settings, mainly: sysctl kern.dsched_debug: the higher the level, the more debug you'll get. By default no debug will be printed. At level 4, only the disk busy-% will be printed, and at 7 all details about the balancing will be shown. test/dsched_fq: If you build fqstats (just using 'make' in this directory), you'll be able to read some of the statistics that dsched_fq keeps track of, such as number of allocated structures of each type and number of processes/threads that were rate limited, number of issued transactions, completed transactions and cancelled transactions. Cheers, Alex Hornung
