From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 20:27:53 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B709106566B; Wed, 25 Jul 2012 20:27:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 56EB68FC14; Wed, 25 Jul 2012 20:27:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA22830; Wed, 25 Jul 2012 23:27:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Su8BS-000934-4E; Wed, 25 Jul 2012 23:27:50 +0300 Message-ID: <501056C4.3080806@FreeBSD.org> Date: Wed, 25 Jul 2012 23:27:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 20:27:53 -0000 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. -- Andriy Gapon