Date: Tue, 9 Feb 2010 00:44:31 -0500 From: jhell <jhell@DataIX.net> To: Michael Vince <mv@thebeastie.org> Cc: Jordi Espasa Clofent <jespasac@minibofh.org>, freebsd-stable@freebsd.org Subject: Re: ionice in FreeBSD? Message-ID: <alpine.BSF.2.00.1002090025540.10638@pragry.qngnvk.ybpny> In-Reply-To: <4B70E66F.2040203@thebeastie.org> References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B70E66F.2040203@thebeastie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1002090025540.10638>