lkml.org 
[lkml]   [2001]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectBlock device strategy and requests
I'm designing a block device driver for a high performance disk
subsystem with unusual characteristics. To what extent is the
limited number of "struct request"s (128 by default) necessary for
back-pressure? With this I/O subsystem it would be possible for the
strategy function to rip the requests from the request list straight
away, arrange for the I/Os to be done to/from the buffer_heads (with
no additional state required) with no memory "leak". This would
effectively mean that the only limit on the number of I/Os queued
would be the number of buffer_heads allocated; not a fixed number of
"struct request"s in flight. Is this reasonable or does any memory or
resource balancing depend on the number of I/Os outstanding being
bounded?

Also, there is a lot of flexibility in how often interrupts are sent
to mark the buffer_heads up-to-date. (With the requests pulled
straight off the queue, the job of end_that_request_first() in doing
the linked list updates and bh->b_end_io() callbacks would be done by
the interrupt routine directly.) At one extreme, I could take an
interrupt for each 4K block issued and mark it up-to-date very
quickly making for very low-latency I/O but a very large interrupt
rate when I/O throughput is high. The alternative would be to arrange
for an interrupt every n buffer_heads (or based on some other
criterion) and only take an interrupt and mark buffers up-to-date on
each of those). Are there any rules of thumb on which is best or
doesn't it matter too much?

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
-
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 12:52    [W:0.037 / U:1.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site