geom <-> cam disk

[Alexander Motin]

On 25.07.2012 23:27, Andriy Gapon wrote:
> Preamble.  I am trying to understand in detail how things work at GEOM <-> "CAM
> disk" boundary.  I am looking at scsi_da and ata_da which seem to be twins in
> this respect.
>
> I got an impression that the bioq_disksort calls in the strategy methods and the
> related queues are completely useless in the GEOM single-threaded world.
> There is only one thread, g_down, that can call a strategy method, the method
> enqueues a bio, then calls a schedule function and through xpt_schedule the call
> flow continues to a start method which dequeues the bio and off it goes.
> I currently can see how a bio queue can accumulate more than one bio.
>
> What am I missing? :-)
> I will be very glad to learn more about this layer if anyone is willing to
> educate me.
> Thank you in advance.
>
> P.S. I wrote a very simple to DTrace script to my "theory" experimentally and my
> testing with various workloads didn't disprove the theory so far (which doesn't
> mean that it is correct, of course).
>
> The script:
> fbt::bioq_disksort:entry
> /args[0]->queue.tqh_first == 0/
> {
>          @["empty"] = count();
> }
>
> fbt::bioq_disksort:entry
> /args[0]->queue.tqh_first != 0/
> {
>          @["non-empty"] = count();
> }
>
> It works on all bioq_disksort calls, but I stressing only ada disks at the moment.

Different controllers have different command queueing limitations. If 
you are testing with ahci(4) driver and modern disks, then their 32 
command slots per port can be enough for many workloads to enqueue all 
commands to the hardware and leave queue empty as you've described. But 
if you take harder workload, or controller/ device without command 
queueing support, extra requests will be accumulated on that bioq and 
sorted there.

-- 
Alexander Motin