lkml.org 
[lkml]   [2002]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] deadline io scheduler
On Thu, Sep 26 2002, Andrew Morton wrote:
> Andrew Morton wrote:
> >
> > I'll test scsi now.
> >
>
> aic7xxx, Fujitsu "MAF3364L SUN36G" (36G SCA-2)
>
>
> Maximum number of TCQ tags=253
>
> fifo_batch time cat kernel/*.c (seconds)
> 64 58
> 32 54
> 16 20
> 8 58
> 4 1:15
> 2 53
>
> Maximum number of TCQ tags=4
>
> fifo_batch time cat kernel/*.c (seconds)
> 64 53
> 32 39
> 16 33
> 8 21
> 4 22
> 2 36
> 1 22
>
>
> Maximum number of TCQ tags = 0:
>
> fifo_batch time cat kernel/*.c (seconds)
> 64 22
> 32 10.3
> 16 10.5
> 8 5.5
> 4 3.2
> 2 1.9
>
> I selected fifo_batch=16 and altered writes_starved and read_expires
> again. They made no appreciable difference.

Abysmal. BTW, fifo_batch value less than seek cost doesn't make too much
sense, unless the drive has really slow streaming io performance.

> >From this I can only conclude that my poor little read was stuck
> in the disk for ages while TCQ busily allowed new incoming writes
> to bypass already-sent reads.
>
> A dreadful misdesign. Unless we can control this with barriers,
> and if Fujutsu is typical, TCQ is just uncontrollable. I, for
> one, would not turn it on in a pink fit.

I have this dream that we might be able to control this if we get our
hands on the queueing at the block level. The above looks really really
bad though, in the past I've had quite good experience with a tag depth
of 4. I should try ide tcq again, to see how that goes.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site