From: Ulf Hansson <ulf.hansson@linaro.org>
To: Linus Walleij <linus.walleij@linaro.org>,
Adrian Hunter <adrian.hunter@intel.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Pavel Machek <pavel@ucw.cz>,
"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: Wed, 4 Oct 2017 10:01:45 +0200 [thread overview]
Message-ID: <CAPDyKFo+KehnATz5RWJN0JngZAYdCEd-EEjXbv9y8oU_Q1Leaw@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdYPn3xxZQP+xXggPpoHercBL3L7dmMBnbXww5SEsFx5tg@mail.gmail.com>
On 4 October 2017 at 09:53, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Oct 3, 2017 at 8:30 AM, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 02/10/17 17:09, Linus Walleij wrote:
>>> On Sun, Oct 1, 2017 at 12:57 PM, Tetsuo Handa
>>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>>
>>>>>> I inserted u-SD card, only to realize that it is not detected as it
>>>>>> should be. And dmesg indeed reveals:
>>>>>
>>>>> Tetsuo asked me to report this to linux-mm.
>>>>>
>>>>> But 2^4 is 16 pages, IIRC that can't be expected to work reliably, and
>>>>> thus this sounds like MMC bug, not mm bug.
>>>
>>>
>>> I'm not sure I fully understand this error message:
>>> "worker/2:1: page allocation failure: order:4"
>>>
>>> What I guess from context is that the mmc_init_request()
>>> call is failing to allocate 16 pages, meaning for 4K pages
>>> 64KB which is the typical bounce buffer.
>>>
>>> This is what the code has always allocated as bounce buffer,
>>> but it used to happen upfront, when probing the MMC block layer,
>>> rather than when allocating the requests.
>>
>> That is not exactly right. As I already wrote, the memory allocation used
>> to be optional but became mandatory with:
>>
>> commit 304419d8a7e9204c5d19b704467b814df8c8f5b1
>> Author: Linus Walleij <linus.walleij@linaro.org>
>> Date: Thu May 18 11:29:32 2017 +0200
>>
>> mmc: core: Allocate per-request data using the block layer core
>
> Yes you are right, it used to look like this, with the bounce buffer
> hiding behind a Kconfig symbol:
>
> #ifdef CONFIG_MMC_BLOCK_BOUNCE
> if (host->max_segs == 1) {
> unsigned int bouncesz;
>
> bouncesz = MMC_QUEUE_BOUNCESZ;
>
> if (bouncesz > host->max_req_size)
> bouncesz = host->max_req_size;
> if (bouncesz > host->max_seg_size)
> bouncesz = host->max_seg_size;
> if (bouncesz > (host->max_blk_count * 512))
> bouncesz = host->max_blk_count * 512;
>
> if (bouncesz > 512 &&
> mmc_queue_alloc_bounce_bufs(mq, bouncesz)) {
> blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_ANY);
> blk_queue_max_hw_sectors(mq->queue, bouncesz / 512);
> blk_queue_max_segments(mq->queue, bouncesz / 512);
> blk_queue_max_segment_size(mq->queue, bouncesz);
>
> ret = mmc_queue_alloc_bounce_sgs(mq, bouncesz);
> if (ret)
> goto cleanup_queue;
> bounce = true;
> }
> }
> #endif
>
> I recently concluded that I find no evidence whatsoever that anyone
> turned this symbol on. Actually. (Checked defconfigs and distro configs.)
> The option was just sitting there unused.
> This code was never exercised except by some people who turned it
> on on their custom kernels in the past. It's in practice dead code.
>
> My patch started to allocate and use bounce buffers for all hosts
> with max_segs == 1, unless specifically flagged NOT to use bounce
> buffers.
>
> That wasn't smart, I should have just deleted them. Mea culpa.
>
> So that is why I asked Ulf to simply put the patch deleting the bounce
> buffers that noone is using to fixes, and it should fix this problem.
Adrian, Linus,
Thanks for looking into the problem! I am queuing up the patch
deleting bounce buffers for fixes asap!
Kind regards
Uffe
next prev parent reply other threads:[~2017-10-04 8:01 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
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 [this message]
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=CAPDyKFo+KehnATz5RWJN0JngZAYdCEd-EEjXbv9y8oU_Q1Leaw@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=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).