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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
