location of bioq lock

From: Luigi Rizzo <rizzo_at_icir.org>
Date: Fri, 8 Jul 2005 11:07:42 -0700
[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.
Received on Fri Jul 08 2005 - 16:07:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC