Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Feb 2002 13:31:14 -0700
From:      "Justin T. Gibbs" <gibbs@scsiguy.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        mjacob@feral.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata ata-disk.c 
Message-ID:  <200202242031.g1OKVEI79628@aslan.scsiguy.com>
In-Reply-To: Your message of "Sun, 24 Feb 2002 20:31:24 %2B0100." <37516.1014579084@critter.freebsd.dk> 

next in thread | previous in thread | raw e-mail | index | archive | help
>>I always assumed it would be used by softupdates to increase the speed
>>of fsync operations.  By using the barrier, you can commit all deps
>>asynchronously in the correct order with the appropriate barriers and
>>maximize the device's queue optimizations.  In other words:
>
>Well, I talked with Kirk, and softupdates relies on the dependencies 
>instead.

I know, and speeding up its clock in the pending removes may free up
needed free space case, etc.  It just seems to me that this could be
simplified (and accelerated) by just queuing the stuff and relying on
device ordering semantics instead.

As I said, even if Kirk decides not to use it, there are other applications
where this feature is useful.  I don't think that FFS should be the only
arbiter for such a feature.

>The problem with BIO_ORDERED is that it totally makes a mess of prioritized
>I/O queuing because you might conceiveably get a low-pri BIO_ORDERED which
>has to flush out hi-pri stuff.

It puts a barrier across which seek optimizations cannot occur, but there
is no "flushing" involved.  Regardless, most systems will see few ordered
transactions (and even fewer from a niced process that is not allowed
to schedule I/O very often) so I don't see this as a strong reason to
prevent an application from using this feature to accelerate I/O. 

--
Justin

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202242031.g1OKVEI79628>