Pierre Ossman <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> >> I have a hard time believe that device hardware limits don't allow them >> to have enough space to handle larger requests. If so it was a poor >> design by the hardware manufacturers. >> > > In the MMC layer, the block size is a major bottle neck. None of the currently > supported hardware supports scatter/gather so we're restricted to servicing a > single continuous chunk of memory at a time. And since latency is substantial > for MMC/SD, good performance is several orders above 4k. We get ~8 MB/s for > cards which are supposed to do 20 MB/s (which has been tested against other > systems where we can get larger memory chunks), and the peasants are getting a > bit unruly. > > I plan to experiment with some bounce buffer scheme to get performance up, but > getting large blocks directly would make such hacks unnecessary.
My problem with the proposed scheme is not that it uses large pages, but rather that it requires large pages. So in the mmc case you would go from getting 20MB/s soon after the system booted to failing to be able to do I/O at all a couple of days later when memory gets fragmented. I think a reliable 8MB/s is much better than an unreliable 20MB/s. With your bounce buffer scheme it seems probable that we can even get a reliable 20MB/s. So I'm interested to hear that we have several in tree users that could benefit. I do think large block support if we don't require large pages makes sense. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
