Re: [00/17] Large Blocksize Support V3

Pierre Ossman <drzeus-list@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: High memory
    ... memory and then copy it up above 1MB...but if you want to put ... outside the CPU, memory is seen in a completely different light...this ... 1MB with "real mode memory" labelled on it or anything...the actual memory ... the system bus to actual hardware devices...hence, ...
    (alt.lang.asm)
  • Re: Crashes and the Blue Screen of Death!
    ... but the most common cause is hardware failure. ... The most common cause of this is hardware memory corruption. ... are listed on the Windows 2000 Hardware Compatibility List. ... recommended that all users install them as they become available. ...
    (microsoft.public.win2000.general)
  • Re: The variable bit cpu
    ... > However looking at the big picture the effort to scale fixed bit hardware ... those bits are kept in the opcode rather than in each memory ... And while a *few* applications might need to scale beyond 256 bits, ... And one *big* thing you're missing here is that have a variable-bit ...
    (alt.lang.asm)
  • SUMMARY: V880 crashes
    ... Almost all suggested it is hardware problem. ... Next day I got a call from SUN and SUN's engineer ... came and replaced two memory DIMMs. ... Second, call support. ...
    (SunManagers)
  • Re: Windows installation problem. Help.
    ... 2004 Windows MVP "Winny" Award ... tries to read the memory, can't find it, generates a processor fault, ... This Stop message usually occurs after the installation of faulty hardware ...
    (microsoft.public.windowsxp.general)