From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 04:55:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A991065679 for ; Tue, 9 Feb 2010 04:55:51 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from mail.jumbuck.com (p82.jumbuck.com [206.112.99.82]) by mx1.freebsd.org (Postfix) with ESMTP id A05258FC14 for ; Tue, 9 Feb 2010 04:55:51 +0000 (UTC) Received: from mail.jumbuck.com (mail.jumbuck.com [206.112.99.82]) by mail.jumbuck.com (Postfix) with ESMTP id F3CF9DDAB138; Tue, 9 Feb 2010 04:38:12 +0000 (UTC) Received: from [127.0.0.1] (ppp191-232.static.internode.on.net [59.167.191.232]) (Authenticated sender: hostmaster@jumbuck.com) by mail.jumbuck.com (Postfix) with ESMTPA id 3EFC4DDAAC1E; Tue, 9 Feb 2010 04:38:12 +0000 (UTC) Message-ID: <4B70E66F.2040203@thebeastie.org> Date: Tue, 09 Feb 2010 15:37:03 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jordi Espasa Clofent References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> In-Reply-To: <4B696360.3070209@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ionice in FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 04:55:51 -0000 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