From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 05:44:32 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 60EC31065695 for ; Tue, 9 Feb 2010 05:44:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.221.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF048FC14 for ; Tue, 9 Feb 2010 05:44:31 +0000 (UTC) Received: by qyk10 with SMTP id 10so267760qyk.4 for ; Mon, 08 Feb 2010 21:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=NKMzzs9yaxgLBWZbtzGquhzTniTjQRNH5AcNIiIKTnA=; b=wLvhMLK5i+50Bu8SxQvG8twxpjEFvnJxgeEifPUN4rLeePowFoxbUQLPFzZRPNMUiJ UwB2PZ/s8m7DuNtRjY/oUkmnmz/7id1IkQNAVIFenbDm9kJD35QjvhJswL5i1x26sfJb wLauBb+wYSYoYweLu790dyzr0F+stxOy+yk0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=wbLi4GRSoGlulLU4wSgfDpJeStxBrvkb8Cwq1bbwYR286yxLDh8XZ/GGA+7oEZwVjV eS1hvJUhy3aVtGWooI4ZDDFkSkUJIK6T6VG/Aultro0OHiIKldvrBv3lOU0Ca4mRmc2b 4Gf8k5VbbReqCiz4wFqTps+vOvs4+p26ZdUeA= Received: by 10.229.62.84 with SMTP id w20mr992160qch.96.1265694271402; Mon, 08 Feb 2010 21:44:31 -0800 (PST) Received: from centel.dataix.local (ppp-21.32.dialinfree.com [209.172.21.32]) by mx.google.com with ESMTPS id 20sm3577475qyk.13.2010.02.08.21.44.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Feb 2010 21:44:29 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 9 Feb 2010 00:44:31 -0500 From: jhell To: Michael Vince In-Reply-To: <4B70E66F.2040203@thebeastie.org> Message-ID: References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B70E66F.2040203@thebeastie.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jordi Espasa Clofent , 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 05:44:32 -0000 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