From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 18 02:31:16 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DCBE16A419 for ; Thu, 18 Oct 2007 02:31:16 +0000 (UTC) (envelope-from brunotm@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 23A5C13C448 for ; Thu, 18 Oct 2007 02:31:16 +0000 (UTC) (envelope-from brunotm@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so18586rvb for ; Wed, 17 Oct 2007 19:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IhL6eh0BNfqVE7cQmTO8E9kAiMVr3MacEBeoYV9Tf0o=; b=rKmPKpnNhJPJRBJsRdjXonro3LUdM68wPCsfT2OBQK4+Rr9fbU8AndeK6rvZ7dePuz28gSKzuMlnveONtDkbiT8o+62RmOd530MOtDcEzPKpP9qnYyveHxnYSdyrH5ProgHFcYXnaS8dz9TZ9De/iePR700u5NIKfBMQrhXj3G0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RVZl0Jv57Q18QxZnC4uabPLXM5rrD8ZmgHTB5qlnK+nk/RGLXxynBLX8eNqXRHgWd/TcRh0hZGTb15SD8EElxT8ToZbhqIuk1Omg6q8Ho89gId6VsXO25OPJ6+YSuUnD7+AJyDSeFkBrI+LoCbKo3efZvBw+BobcPrvRxxHGuJ0= Received: by 10.114.197.1 with SMTP id u1mr2648waf.1192672940033; Wed, 17 Oct 2007 19:02:20 -0700 (PDT) Received: by 10.114.56.5 with HTTP; Wed, 17 Oct 2007 19:02:19 -0700 (PDT) Message-ID: <787586d00710171902o59c82171y1e972ff51c2174b6@mail.gmail.com> Date: Thu, 18 Oct 2007 00:02:19 -0200 From: "Bruno Tavares" To: "Ulf Lilleengen" , freebsd-hackers@freebsd.org, s223560@studenti.ing.unipi.it, luigi@freebsd.org In-Reply-To: <20071017143954.GU99087@gandalf.sssup.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071011022001.GC13480@gandalf.sssup.it> <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de> <20071017110715.GA25075@stud.ntnu.no> <20071017121907.GL99087@gandalf.sssup.it> <20071017130934.GA26180@stud.ntnu.no> <20071017143954.GU99087@gandalf.sssup.it> Cc: Subject: Re: Pluggable Disk Scheduler Project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 02:31:16 -0000 On 10/17/07, Fabio Checconi wrote: > > From: Ulf Lilleengen > > Date: Wed, Oct 17, 2007 03:09:35PM +0200 > > > > On ons, okt 17, 2007 at 02:19:07 +0200, Fabio Checconi wrote: > > > Maybe I've not enough experience/knowledge of the driver subsystem, > [...] > > If you look at it, Hybrid is just a generalization of the existing > > bioq_* API already defined. And this API is used by GEOM classes _before_ > > device drivers get the requests AFAIK. > > > > I looked at the Hybrid code, but I don't think that the bioq_* > family of calls can be the right place to start, for the problems > experienced during the Hybrid development with locking/anticipation > and because you can have the same request passing through multiple > bioqs during its path to the device (e.g., two stacked geoms using > two different bioqs and then a device driver using bioq_* to organize > its queue, or geoms using more than one bioq, like raid3; I think > the complexity can become unmanageable.) One could even think to > configure each single bioq in the system, but things can get very > complex in this way. > > > > For a simple example on a driver, the md-driver might be a good place to > > look. Note that I have little experience and knowledge of the driver > > subsystem myself. > > > > I'll take a look, thanks. > > > > Also note (from the Hybrid page): > > * we could not provide support for non work-conserving schedulers, due to a > [...] > > > > This certainly argues for having this in the GEOM layer, but perhaps it's > > possible to change the assumtions done in some drivers? The locking issue > > should perhaps be better planned though, and an audit of the driver disksort > > code is necessary. > > > > I need some more time to think about that :) > > > > Also: > > * as said, the ATA driver in 6.x/7.x moves the disksort one layer below the > > one we are working at, so this particular work won't help on ATA-based 6.x > > machines. > > We should figure out how to address this, because the work done at that > > layer is mostly a replica of the bioq_*() API. > > > > So, I see this can get a bit messy thinking of that the ATA drivers does > > disksorts on its own, but perhaps it would be possible to fix this by letting > > changing the general ATA driver to use it's own pluggable scheduler. > > > > Anyway, I shouldn't demand that you do this, especially since I don't have > > any code or anything to show to, and because you decide what you want to do. > > I still cannot say if a GEOM scheduler is better than a scheduler > put at a lower level, or if the bioq_* interface is better than any > other alternative, so your suggestions are welcome. Moreover I'd > really like to discuss/work together, or at least do things with > some agreement on them. If I'll have the time to experiment with > more than one solution I'll be happy to do that. > > > > However, I'd hate to see the Hybrid effort go to waste :) I was hoping some > > of the authors of the project would reply with their thoughts, so I CC'ed > > them. > > Well, the work done on Hybrid had also interesting aspects from > the algorithm side... but that's another story... > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- This .signature sanitized for your protection