From owner-freebsd-hackers  Sun Mar 12  5:58:39 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id A625337BC03
	for <freebsd-hackers@FreeBSD.ORG>; Sun, 12 Mar 2000 05:58:33 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id OAA73815;
	Sun, 12 Mar 2000 14:58:26 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003121358.OAA73815@freebsd.dk>
Subject: Re: ATA-disk question
In-Reply-To: <20000311173548.A1570@cs.rice.edu> from Sitaram Iyer at "Mar 11, 2000 05:35:48 pm"
To: ssiyer@cs.rice.edu (Sitaram Iyer)
Date: Sun, 12 Mar 2000 14:58:26 +0100 (CET)
Cc: freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Sitaram Iyer wrote:
> (kernel 4.0-20000208-CURRENT)
> 
> I have a question about adstrategy() in ata-disk.c: it says
> 
> 	bufqdisksort() -- which appends to the drive queue using CSCAN,
> 
> and immediately, without a check for adp->active, there is
> 
> 	ad_start() -- which removes it from there and puts it into the
> 		      controller queue, thereby nullifying CSCAN's effect
> 		      completely (drive queue length always = 0 or 1) and
> 		      blowing up the controller TAILQ to occasional spurts
> 		      with tens of requests (I measured this).
> 
> on browsing through cvsweb, I find that such a check used to be there
> earlier ( bufqdisksort(&adp->queue, bp); if (!adp->active) ad_start(adp); )
> till "1.14 Fri Jun 25 9:02:59 1999 UTC by sos" (the 9th ATA update), and the
> only thing in the commit log that's making sense to me is:
> 
> 	"The disk driver has been changed a bit to prepare for tagged
> 	queing, which is next on my list." -- sos
> 
> What's the exact rationale behind doing away with CSCAN? is it temporary?
> Its not entirely clear to me how "tagged queueing" (whatever that is) would
> remedy the fact that requests are taken away from drive queues as soon as
> they're put there.

This was part of the code for tagged queueing, but since that has been
put on hold for now, this is clearly a bug. Tagged queueing is the term
for having multiple outstanding requests on the disk, and let the disk
sort out in which ord to complete them.

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message