On Fri, May 19, 2017 at 9:30 AM, Steven J. Hill <Steven.Hill@xxxxxxxxxx> wrote:
> Remove MMC bounce buffer config option and associated code. This
> is proposed in addition to Linus' changes to remove the config
> option. I have tested this on our Octeon hardware platforms.
>
> Signed-off-by: Steven J. Hill <Steven.Hill@xxxxxxxxxx>
This would have to be rebased as Ulf merged my patch making this
a per-host runtime config option. (The Kconfig is gone for example.)
Bounce buffers were added by Pierre Ossman for kernel 2.6.23 in
commit 98ccf14909ba02a41c5925b0b2c92aeeef23d3b9
"mmc: bounce requests for simple hosts"
Quote:
Some hosts cannot do scatter/gather in hardware. Since not doing sg
is such a big performance hit, we (optionally) bounce the requests
to a simple linear buffer that we hand over to the driver.
Signed-off-by: Pierre Ossman <drzeus@xxxxxxxxx>
So this runs the risk on reducing performance on simple MMC/SD
controllers. Notice: simple, not old.
We need to know if people are deploying simple controllers still
and if this is something that really affects their performance.
That said: this was put in place because the kernel was sending
SG lists that the host DMA could not manage.
Nowadays we have two mechanisms:
- DMA engine and DMA-API that help out in managing bounce
buffers when used. This means this only is useful for hardware
that does autonomous DMA, without any separate DMA engine.
- CMA that can actually allocate a big chunk of memory: I think
this original code is restricted to a 64KB segment because
kmalloc() will only guarantee contigous physical memory up to
64-128KiB or so. Now we could actually allocate a big badass
CMA buffer if that improves the performance, and that would be
a per-host setting.
It would be good to hear from people seeing benefits from bounce
buffers about this. What hardware is there that acually sees a
significant improvement with bounce buffers?
Pierre, what host were you developing this for? Maybe I can try
to get the same and test it.
Yours,
Linus Walleij
