Date: Wed, 25 Jul 2012 14:14:02 -0700 From: Scott Long <scottl@samsco.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org, freebsd-geom@freebsd.org Subject: Re: geom <-> cam disk Message-ID: <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> In-Reply-To: <501056C4.3080806@FreeBSD.org> References: <501056C4.3080806@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Once the bio is put into the bioq from da_strategy, the CAM scheduler is = called. It may or may not wind up calling dastart right away; if the = simq or devq is frozen, or if the devq has been exhausted, then the io = will be deferred until later and the call stack will unwind back into = g_down. The bioq can therefore accumulate many bio's before being = drained. Draining will usually happen from the camisr, at which point = you can potentially have i/o being initiated from both the camisr and = the g_down threads in parallel. The monolithic locking in CAM right now = prevents this from actually happening, though that's a topic that needs = to be revisited. Scott On Jul 25, 2012, at 1:27 PM, Andriy Gapon wrote: >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > The script: > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first =3D=3D 0/ > { > @["empty"] =3D count(); > } >=20 > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first !=3D 0/ > { > @["non-empty"] =3D count(); > } >=20 > It works on all bioq_disksort calls, but I stressing only ada disks at = the moment. > --=20 > Andriy Gapon >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23011628-17F1-49A0-A41E-E7A8A8E3EA64>