From owner-freebsd-stable@FreeBSD.ORG Wed Feb 3 11:52:03 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 AC6F41065672 for ; Wed, 3 Feb 2010 11:52:03 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.56]) by mx1.freebsd.org (Postfix) with ESMTP id 6DFB98FC0C for ; Wed, 3 Feb 2010 11:52:03 +0000 (UTC) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) (Authenticated sender: jespasac@noverificar) by smtp02.cdmon.com (Postfix) with ESMTP id 4817645BD6 for ; Wed, 3 Feb 2010 12:52:01 +0100 (CET) Message-ID: <4B696360.3070209@minibofh.org> Date: Wed, 03 Feb 2010 12:52:00 +0100 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> In-Reply-To: <4B695A1A.1000505@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 03 Feb 2010 11:52:03 -0000 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. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear.