From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 23:22:16 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 958E216A41C; Tue, 12 Jul 2005 23:22:16 +0000 (GMT) (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 5890343D49; Tue, 12 Jul 2005 23:22:16 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6CNMGic058656; Tue, 12 Jul 2005 16:22:16 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6CNMFDo058655; Tue, 12 Jul 2005 16:22:15 -0700 (PDT) (envelope-from rizzo) Date: Tue, 12 Jul 2005 16:22:15 -0700 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20050712162215.B58434@xorpc.icir.org> References: <42D419C2.6040606@samsco.org> <33782.1121198594@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <33782.1121198594@phk.freebsd.dk>; from phk@haven.freebsd.dk on Tue, Jul 12, 2005 at 10:03:14PM +0200 Cc: Robert Watson , s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: location of bioq lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2005 23:22:16 -0000 On Tue, Jul 12, 2005 at 10:03:14PM +0200, Poul-Henning Kamp wrote: > > I must admit that I have often been tempted to move the queue+sorting > out of the drivers because they all, more or less, do the exact > same thing. > > For one thing, that would simplify any ABI for changing disksort > algorithm (which should be per drive and not per system). yes this is true - in fact we are looking at the feasibility of a per-drive disksort too. What is really complex with the current infrastructure is implementing non work-conserving algorithms, e.g. the anticipatory scheduling (see http://www.cs.rice.edu/~ssiyer/r/antsched/ ) because there you need to hook into the equivalent of if_start() for network interfaces, and at the moment each driver does it in a different way... > The last bit of this is that disksorting seldom does much for us > these days, apart from mitigating the the lemming syncer. true again... (not that i dobted that phk knows a lot here :) in fact i see it more as something to improve fairness, rather than something to improve throughput. cheers luigi