In message <20020626182023.GH7973@widomaker.com>, Charles Shannon Hendrix write
s:
>On Thu, Jun 20, 2002 at 07:02:28PM +0200, Manuel Bouyer wrote:
>> On Thu, Jun 20, 2002 at 02:22:58AM -0400, Charles Shannon Hendrix wrote:
>> > [...]
>> > Isn't the I/O queue processed in a way that limits heavy I/O processes
>> > to give better response time for infrequent I/O processes?  If it is,
>> > is this tunable?
>> 
>> Well, no, it's not unfortunably. It's a simple queue. Disksort will try
>> to keep the queue ordered by block numbers (to minimize seeks), which makes
>> things even worse: with a large sequential write to a to one partition,
>> an I/O for another one will always be put at the end of the queue (or at
>> last after the entries of the sequential writes), while newer entries for
>> the sequential write will be inserted before this I/O.
>
>That's too bad.  It would be nice if it could break order after a
>process had passed some I/O limit.  It limits the effect of a common
>tuning method whereby you move applications to separate drives.

Agreed.  I've upgraded several of my machines to 1.6beta2 and beta3, 
and I'm seeing the same symptoms that Wojciech has mentioned.
>
>Ideally, you would limit the effect to shortening the response time for
>the starved and small processes (in terms of I/O), while only slightly
>slowing the freight trains that are eating your bandwidth.
>

Unix-like systems have long had this problem -- the disk-scheduler is 
too far removed from any process's context.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)