On 3/5/13 9:37 PM, Don Lewis wrote:
On 5 Mar, Ian Lepore wrote:
I've debated playing with the bio work loop in mmcsd to see if moving
reads ahead of writes was helpful, but that seems like a dangerous path
to go down without some mitigation strategy to ensure that writes go
through eventually. That seems especially important when you consider
that writes may be necessary to free up memory to un-wedge other things
that are waiting. (Yeah, people don't often use sd cards as swap
storage, but I've done so in a pinch.) All in all, I've never pursued
it because it feels like the wrong layer to address the problem at.
I was initially concerned about the memory starvation problem, but I
don't think it's an issue. If memory is unavailable, then the upper
layer won't be able to allocate the buffer memory for the read requests
and will block before sending any more read commands down to the driver.
I think that large numbers of reads causing write starvation are also
unlikely. A single thread can generate a large backlog of writes
(unless the filesystem is mounted in sync mode), but it generally can't
queue up a lot of reads because the thread is likely to block every time
it issues a read request until it gets the data back from the drive. If
you are still worried about this, you could maintain separate read and
write queues and alternate between them if both are nonempty.
What if we ran reads and writes over the loopback via TCP to get some
kind of windowing? :)
I am only half kidding... it would make sense to look to TCP to allow
for some kind of window of IO based on throughput to the device.
-Alfred
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"
