From owner-freebsd-current@FreeBSD.ORG Fri Jul 8 18:07:43 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 A654416A41C for ; Fri, 8 Jul 2005 18:07:43 +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 72CA243D48 for ; Fri, 8 Jul 2005 18:07:43 +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 j68I7g3m006547; Fri, 8 Jul 2005 11:07:42 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j68I7gXm006546; Fri, 8 Jul 2005 11:07:42 -0700 (PDT) (envelope-from rizzo) Date: Fri, 8 Jul 2005 11:07:42 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20050708110742.A6284@xorpc.icir.org> References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050705103353.A8185@xorpc.icir.org>; from rizzo@icir.org on Tue, Jul 05, 2005 at 10:33:53AM -0700 Cc: s223560@studenti.ing.unipi.it Subject: 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: Fri, 08 Jul 2005 18:07:43 -0000 [see context at the end] Queues of I/O requests are implemented by a struct bio_queue_head in src/sys/sys/bio.h - however the lock for the queue is outside the structure, and, as a result, whoever wants to manipulate this data structure either a) needs it already locked, or b) needs to know which lock to grab. Case a) occurs when someone accesses the bio_queue through the regular API -- the caller already does the required locking. Case b) however can occur when we have some asynchronous request to work on the queue, e.g. to change scheduler. So we need to know where the lock is. I can see two ways: 1) put the lock in the struct bio_queue_head. This is the same thing done in struct g_bioq defined in sys/geom/geom.h . Quite clean, except that perhaps some users of bio_queue_head still run under Giant (e.g. cam/scsi ?) and so it is not possible to 'bring in' the lock. 2) change bioq_init() so that it takes also a pointer to the mtx that protects the queue. This is probably less clean, but perhaps a bit more flexible because the queue and its lock are decoupled. Also it permits to deal with the 'Giant' case easily. Other ideas ? cheers luigi (background - this is related to the work my SoC student Emiliano, in Cc, is doing on pluggalbe disk schedulers) The disk scheduler operates on struct bio_queue_head objects (which include CSCAN scheduler info) and uses 5 methods: bioq_init() initializes the queue. bioq_disksort() to add requests to the queue bioq_first() to peek at the head of the queue bioq_remove() to remove the first element. bioq_flush() right now simply a wrapper around bioq_first() and bioq_remove(), but one could imagine the need for a specific destructor to free memory etc.