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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
