linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Pavel Machek <pavel@ucw.cz>, Linus Walleij <linus.walleij@linaro.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
Date: Tue, 24 Oct 2017 09:59:33 +0300	[thread overview]
Message-ID: <a920ce93-5421-003d-6b19-194f8ea3ee5b@intel.com> (raw)
In-Reply-To: <20171023212741.GA12782@amd>

On 24/10/17 00:27, Pavel Machek 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. 
> 
>> 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.
> 
> (OTOH ... SPI is slow compared to rest of the system, right? Where
> does the benefit come from?)

Do you mean what is the benefit of the bounce buffer?  With SDMA, only a
single segment is transferred at a time - that can mean just a single page
i.e. 4k.  But the buffer is a single segment so it should enable larger
transfer sizes (i.e. buffer size 64k) which performs better.

You need to compare performance with and without the bounce buffer
(particularly when memory is fragmented) to determine how much benefit you get.

  reply	other threads:[~2017-10-24  7:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05 19:47 4.13 on thinkpad x220: oops when writing to SD card Pavel Machek
2017-09-06  2:44 ` Shawn Lin
2017-09-06  6:03   ` Adrian Hunter
2017-09-07  7:18     ` Ulf Hansson
2017-09-07  7:53       ` Adrian Hunter
2017-09-07 10:47         ` Seraphime Kirkovski
2017-09-07 12:06         ` Ulf Hansson
2017-09-07 12:55           ` Pavel Machek
2017-09-07 15:03             ` Ulf Hansson
2017-09-08  8:51           ` Pavel Machek
2017-09-07 19:58         ` Linus Walleij
2017-09-07 20:02       ` Linus Walleij
2017-09-08  2:51         ` Shawn Lin
2017-09-12  9:42           ` Linus Walleij
2017-09-13  4:04             ` Shawn Lin
2017-10-01  9:37 ` 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek
2017-10-01 10:26   ` Pavel Machek
2017-10-01 10:57     ` Tetsuo Handa
2017-10-02  7:52       ` Adrian Hunter
2017-10-02  8:41         ` Pavel Machek
2017-10-02 12:06           ` Linus Walleij
2017-10-02 13:03             ` Pavel Machek
2017-10-03  6:27               ` Adrian Hunter
2017-10-23  9:31                 ` Pavel Machek
2017-10-23 12:13                   ` Adrian Hunter
2017-10-23 12:16                   ` Linus Walleij
2017-10-23 21:27                     ` Pavel Machek
2017-10-24  6:59                       ` Adrian Hunter [this message]
2017-10-26 13:44                       ` Linus Walleij
2017-10-02 14:09       ` Linus Walleij
2017-10-03  6:30         ` Adrian Hunter
2017-10-04  7:53           ` Linus Walleij
2017-10-04  8:01             ` Ulf Hansson
2017-10-02 14:44     ` Michal Hocko
2017-10-02 14:55       ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a920ce93-5421-003d-6b19-194f8ea3ee5b@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).