Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 23, 2017 at 11:27 PM, Pavel Machek <pavel@xxxxxx> wrote:
> On Mon 2017-10-23 14:16:40, Linus Walleij wrote:
>> On Mon, Oct 23, 2017 at 11:31 AM, Pavel Machek <pavel@xxxxxx> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux