lkml.org 
[lkml]   [1998]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Elevator vs first-come-first-served
> > But does it forgo any ordering before it does so?  If it doesn't, this
> > wastes time. For instance, one of the machines here has a 40GB RAID-5
> > with 64MB of cache; the ordering of requests will probably never make
> > a significant difference.
>
> We still do the queue ordering. Whether that makes a difference depends
> on whether or not the cache is battery-backed.

Assume that it is. Assume that our target is a CMD SCSI-SCSI RAID
controller, with 256MB of battery-backed cache, and a few busses with
plenty of attached disks. To us, it just looks like a really big, fast
disk. This is where it may make a significant difference. The mid-range
servers will have to contend with a volatile cache, but they will still
benefit from increased performance. Also, consider read performance, as
for most applications (save for logging, news service, etc.) are much
heavier on the reads than writes. Here the reordering of requests matters
too. But if the administrator has the ability to switch to first-come
first-served, (s)he wins either way.

> There is a strict limit on how much data you can have in transit to the
> disks at once. SCSI has hard limits on tagged command queue depth, and
> most drivers also have such limits. If the cache is volatile, then it
> cannot safely be used for write-behind: you cannot complete the scsi
> command until the data has hit disk, so your asynchronous writes are
> limited by the number of outstanding scsi commands.
>
> In that case, the host queue ordering _will_ make a difference.

Granted, but that is not the most interesting case; I was attempting to
show how switching to a more simple ordering can be beneficial.

As a sidenote, I've been poking around at ll_rw_blk.c and disabling the
elevator looks trivial. I'll fiddle with it and see what sort of disk
throughput changes I get with the different hardware lying around here.

--
Robert Minichino
Chief Engineer
Denarius Enterprises, Inc.


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

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.028 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site