lkml.org 
[lkml]   [2017]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
On Mon, Oct 23, 2017 at 11:27 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2017-10-23 14:16:40, Linus Walleij wrote:
>> On Mon, Oct 23, 2017 at 11:31 AM, Pavel Machek <pavel@ucw.cz> wrote:
>>
>> >> > Thinkpad X220... how do I tell if I was using them? I believe so,
>> >> > because I uncovered bug in them before.
>> >>
>> >> You are certainly using bounce buffers. What does lspci -knn show?
>> >
>> > Here is the output:
>> > 0d:00.0 System peripheral [0880]: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823] (rev 07)
>> > Subsystem: Lenovo Device [17aa:21da]
>> > Kernel driver in use: sdhci-pci
>>
>> So that is a Ricoh driver, one of the few that was supposed to benefit
>> from bounce buffers.
>>
>> Except that if you actually turned it on:
>> > [10994.302196] kworker/2:1: page allocation failure: order:4,
>> so it doesn't have enough memory to use these bounce buffers
>> anyway.
>
> Well, look at archives: driver failed completely when allocation failed.

What I mean is that the allocation probably failed if you
explicitly turned on the bounce buffer also *before*
my patches (like if you were shopping for performance with
the Ricoh driver and turn on bounce buffers) but I haven't tested
it so what do I know.

You could check out b5b6a5f4f06c0624886b2166e2e8580327f0b943
and enable MMC_BLOCK_BOUNCE and see what happens.
And/or benchmark to see if it was actually improving your
system or not.

>> I'm now feel it was the right thing to delete them.
>
> Which means I may have been geting benefit -- when it worked. I
> believe solution is to allocate at driver probing time.

I think the right way to get this benefit is to enhance the
Ricoh SDMA path with something similar to:
commit 0ccd76d4c236 ("omap_hsmmc: Implement scatter-gather
emulation")

What it does is loop over the sglist and smatter out one DMA
transfer per sg index.

It's likely faster than copying back and forth to a bounce
buffer even if there is a deal of HW talk back and forth.

> (OTOH ... SPI is slow compared to rest of the system, right? Where
> does the benefit come from?)

I do not think you will see much performance improvement
on an SPI-based host. Pierre just vaguely remembered "some
Ricoh controllers" would get a benefit from bounce buffers,
no specifics, sorry...

Yours,
Linus Walleij

\
 
 \ /
  Last update: 2017-10-26 15:45    [W:0.090 / U:1.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site