From owner-freebsd-geom@FreeBSD.ORG Fri Jan 5 22:59:18 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A635B16A403; Fri, 5 Jan 2007 22:59:18 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 92A2D13C441; Fri, 5 Jan 2007 22:59:18 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l05MxG5h094398; Fri, 5 Jan 2007 14:59:16 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l05MxFeV094397; Fri, 5 Jan 2007 14:59:15 -0800 (PST) (envelope-from rizzo) Date: Fri, 5 Jan 2007 14:59:15 -0800 From: Luigi Rizzo To: Paul Allen Message-ID: <20070105145915.B94175@xorpc.icir.org> References: <20070105123127.gnk0v58p44488g48@webmail.ntnu.no> <4085.1167997049@critter.freebsd.dk> <20070105184621.dh8kgoy7ko4gk4gc@webmail.ntnu.no> <20070105102905.A91349@xorpc.icir.org> <20070105212543.GA8574@heave.ugcs.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070105212543.GA8574@heave.ugcs.caltech.edu>; from nospam@nospam.com on Fri, Jan 05, 2007 at 01:25:43PM -0800 Cc: freebsd-current@freebsd.org, lulf@stud.ntnu.no, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Pluggable Disk Schedulers in GEOM X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 22:59:18 -0000 On Fri, Jan 05, 2007 at 01:25:43PM -0800, Paul Allen wrote: > >From Luigi Rizzo , Fri, Jan 05, 2007 at 10:29:05AM -0800: > > Essentially, a process doing e.g. a 'cvs checkout' on a large > > tree will still kill the performance of your disk no matter > > which scheduler you are using (elevator, hybrid, the dumb one that > > we wrote as an example). The reasons, i suspect, are a mixture > > of the ones described above. > > Interaction of the disk scheduler and softupdates? As I understand > the softupdate code, the disk scheduler would be ignorant of I/O that this was also on 4.11 which probably does not use softupdates. > depends on the completion of certain writes because issuing that I/O > to the lower layers is delayed until the equiv of bio_done occurs. > > I don't see what use a disk scheduler would be unless it is possible > to push information about any partial ordering requirements down to > the level at which the scheduler can see and enforce them. that does not mean that a scheduler is useless in general. in fact, what i find questionable is hardwiring unnecessary (in the sense that they are done only for performance reasons) ordering constraints in the layers above. I cannot comment for the disk, but e.g. for the process scheduler there are priority updates in many places depending on what the process is doing. cheers luigi