On Mon, 8 Feb 2010 23:37, mv@ wrote:
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
In this thread with due respect to the OP the following might be
considered a fruitless hack but it works!.
Piping a processes output to dd(1) if you have a choice is a pretty fair
temporary solution if a program does not offer that capability.
For instance, I don't know if you are familiar with dump(8) at all, but I
use a -P or pipe from that process to dd(8) to slow down the traffic that
it tries to write over the network for backup purposes and then also give
dump(8) a different nice level so it plays along.
So even if you can cat your output and then read it in from fd(4) using
dd(8) you still have a chance at slowing things down a little or writing
at smaller increments that wont impact your environment as hard.
;)
--
jhell
_______________________________________________
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"
