Date: Tue, 12 Jul 2005 16:22:15 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Poul-Henning Kamp <phk@haven.freebsd.dk> Cc: Robert Watson <rwatson@freebsd.org>, s223560@studenti.ing.unipi.it, current@freebsd.org Subject: Re: location of bioq lock Message-ID: <20050712162215.B58434@xorpc.icir.org> In-Reply-To: <33782.1121198594@phk.freebsd.dk>; from phk@haven.freebsd.dk on Tue, Jul 12, 2005 at 10:03:14PM %2B0200 References: <42D419C2.6040606@samsco.org> <33782.1121198594@phk.freebsd.dk>
index | next in thread | previous in thread | raw e-mail
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 luigihelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050712162215.B58434>