On 3/02/2010 10:52 PM, Jordi Espasa Clofent wrote:
On 02/03/2010 12:12 PM, Bruce Simpson wrote:
On 02/02/2010 17:19, Jordi Espasa Clofent wrote:
In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if
I'm understanding correctly, they're related to CPU priorty only, not
to I/O.
That's not entirely true.
A thread's CPU priority is still going to affect its ability to be
scheduled on the CPU, and if it's waiting in the read() or write()
syscalls, then this will make a difference to how quickly it can
complete the next call.
Yes. I've already supposed it.
However, it doesn't explicitly affect relative I/O prioritization. This
is another story entirely. I suspect in a lot of cases adding a weight
to per thread I/O, isn't going to make much difference for disk I/Os
which are being sorted for the geometry (e.g. AHCI NCQ).
So I guess my question is, 'why do you need I/O scheduling, and what
aspect of system performance are you trying to solve with it' ?
Some shell-scripts based on dd or rsync, for example. Even a daily
antivirus (ClamAV) scanner means an extensive I/O.
Programs like Rsync do provide --bwlimit= which work great in slowing it
down to a desired level.
I can't help but think every program that can use too much IO should
have it's own IO/speed switch of some sort.
I can only hope that in general nix evolution that all programs that can
over use IO will offer a switch to slow it down like Rsync does.
Using a while ionice can be a useful feature it can also be said that
there are too many instances where it's being used as a hack to deal
with a program that isn't offering all the functionality that it should.
Cheers,
Mike
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"