All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, pavel@ucw.cz
Cc: linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-mm@kvack.org, linus walleij <linus.walleij@linaro.org>
Subject: Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
Date: Mon, 2 Oct 2017 10:52:46 +0300	[thread overview]
Message-ID: <72c93a69-610f-027e-c028-379b97b6f388@intel.com> (raw)
In-Reply-To: <201710011957.ICF15708.OOLOHFSQMFFVJt@I-love.SAKURA.ne.jp>

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

There is also a bug in mmc_init_request() where it doesn't free it's
allocations on the error path, so you might want to check if you are leaking
memory.

Bounce buffers are being removed from v4.15 although you may experience
performance regression with that:

	https://marc.info/?l=linux-mmc&m=150589778700551



On 01/10/17 13:57, Tetsuo Handa wrote:
> Pavel Machek wrote:
>> Hi!
>>
>>> 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.
> 
> Yes, 16 pages is costly allocations which will fail without invoking the
> OOM killer. But I thought this is an interesting case, for mempool
> allocation should be able to handle memory allocation failure except
> initial allocations, and initial allocation is failing.
> 
> I think that using kvmalloc() (and converting corresponding kfree() to
> kvfree()) will make initial allocations succeed, but that might cause
> needlessly succeeding subsequent mempool allocations under memory pressure?
> 
>>
>>> [10994.299846] mmc0: new high speed SDHC card at address 0003
>>> [10994.302196] kworker/2:1: page allocation failure: order:4,
>>> mode:0x16040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), nodemask=(null)
>>> [10994.302212] CPU: 2 PID: 9500 Comm: kworker/2:1 Not tainted
>>> 4.14.0-rc2 #135
>>> [10994.302215] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET73WW
>>> (1.43 ) 10/12/2016
>>> [10994.302222] Workqueue: events_freezable mmc_rescan
>>> [10994.302227] Call Trace:
>>> [10994.302233]  dump_stack+0x4d/0x67
>>> [10994.302239]  warn_alloc+0xde/0x180
>>> [10994.302243]  __alloc_pages_nodemask+0xaa4/0xd30
>>> [10994.302249]  ? cache_alloc_refill+0xb73/0xc10
>>> [10994.302252]  cache_alloc_refill+0x101/0xc10
>>> [10994.302258]  ? mmc_init_request+0x2d/0xd0
>>> [10994.302262]  ? mmc_init_request+0x2d/0xd0
>>> [10994.302265]  __kmalloc+0xaf/0xe0
>>> [10994.302269]  mmc_init_request+0x2d/0xd0
>>> [10994.302273]  alloc_request_size+0x45/0x60
>>> [10994.302276]  ? free_request_size+0x30/0x30
>>> [10994.302280]  mempool_create_node+0xd7/0x130
>>> [10994.302283]  ? alloc_request_simple+0x20/0x20
>>> [10994.302287]  blk_init_rl+0xe8/0x110
>>> [10994.302290]  blk_init_allocated_queue+0x70/0x180
>>> [10994.302294]  mmc_init_queue+0xdd/0x370
>>> [10994.302297]  mmc_blk_alloc_req+0xf6/0x340
>>> [10994.302301]  mmc_blk_probe+0x18b/0x4e0
>>> [10994.302305]  mmc_bus_probe+0x12/0x20
>>> [10994.302309]  driver_probe_device+0x2f4/0x490
>>>
>>> Order 4 allocations are not supposed to be reliable...
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> 									Pavel
>>>
>>
>>
>>
>> -- 
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 

WARNING: multiple messages have this Message-ID (diff)
From: Adrian Hunter <adrian.hunter@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, pavel@ucw.cz
Cc: linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-mm@kvack.org, linus walleij <linus.walleij@linaro.org>
Subject: Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
Date: Mon, 2 Oct 2017 10:52:46 +0300	[thread overview]
Message-ID: <72c93a69-610f-027e-c028-379b97b6f388@intel.com> (raw)
In-Reply-To: <201710011957.ICF15708.OOLOHFSQMFFVJt@I-love.SAKURA.ne.jp>

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

There is also a bug in mmc_init_request() where it doesn't free it's
allocations on the error path, so you might want to check if you are leaking
memory.

Bounce buffers are being removed from v4.15 although you may experience
performance regression with that:

	https://marc.info/?l=linux-mmc&m=150589778700551



On 01/10/17 13:57, Tetsuo Handa wrote:
> Pavel Machek wrote:
>> Hi!
>>
>>> 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.
> 
> Yes, 16 pages is costly allocations which will fail without invoking the
> OOM killer. But I thought this is an interesting case, for mempool
> allocation should be able to handle memory allocation failure except
> initial allocations, and initial allocation is failing.
> 
> I think that using kvmalloc() (and converting corresponding kfree() to
> kvfree()) will make initial allocations succeed, but that might cause
> needlessly succeeding subsequent mempool allocations under memory pressure?
> 
>>
>>> [10994.299846] mmc0: new high speed SDHC card at address 0003
>>> [10994.302196] kworker/2:1: page allocation failure: order:4,
>>> mode:0x16040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), nodemask=(null)
>>> [10994.302212] CPU: 2 PID: 9500 Comm: kworker/2:1 Not tainted
>>> 4.14.0-rc2 #135
>>> [10994.302215] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET73WW
>>> (1.43 ) 10/12/2016
>>> [10994.302222] Workqueue: events_freezable mmc_rescan
>>> [10994.302227] Call Trace:
>>> [10994.302233]  dump_stack+0x4d/0x67
>>> [10994.302239]  warn_alloc+0xde/0x180
>>> [10994.302243]  __alloc_pages_nodemask+0xaa4/0xd30
>>> [10994.302249]  ? cache_alloc_refill+0xb73/0xc10
>>> [10994.302252]  cache_alloc_refill+0x101/0xc10
>>> [10994.302258]  ? mmc_init_request+0x2d/0xd0
>>> [10994.302262]  ? mmc_init_request+0x2d/0xd0
>>> [10994.302265]  __kmalloc+0xaf/0xe0
>>> [10994.302269]  mmc_init_request+0x2d/0xd0
>>> [10994.302273]  alloc_request_size+0x45/0x60
>>> [10994.302276]  ? free_request_size+0x30/0x30
>>> [10994.302280]  mempool_create_node+0xd7/0x130
>>> [10994.302283]  ? alloc_request_simple+0x20/0x20
>>> [10994.302287]  blk_init_rl+0xe8/0x110
>>> [10994.302290]  blk_init_allocated_queue+0x70/0x180
>>> [10994.302294]  mmc_init_queue+0xdd/0x370
>>> [10994.302297]  mmc_blk_alloc_req+0xf6/0x340
>>> [10994.302301]  mmc_blk_probe+0x18b/0x4e0
>>> [10994.302305]  mmc_bus_probe+0x12/0x20
>>> [10994.302309]  driver_probe_device+0x2f4/0x490
>>>
>>> Order 4 allocations are not supposed to be reliable...
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> 									Pavel
>>>
>>
>>
>>
>> -- 
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 

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

  reply	other threads:[~2017-10-02  7:59 UTC|newest]

Thread overview: 49+ 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-01 10:57       ` Tetsuo Handa
2017-10-02  7:52       ` Adrian Hunter [this message]
2017-10-02  7:52         ` Adrian Hunter
2017-10-02  8:41         ` Pavel Machek
2017-10-02 12:06           ` Linus Walleij
2017-10-02 12:06             ` Linus Walleij
2017-10-02 13:03             ` Pavel Machek
2017-10-03  6:27               ` Adrian Hunter
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:13                     ` Adrian Hunter
2017-10-23 12:16                   ` Linus Walleij
2017-10-23 12:16                     ` Linus Walleij
2017-10-23 21:27                     ` Pavel Machek
2017-10-24  6:59                       ` Adrian Hunter
2017-10-24  6:59                         ` Adrian Hunter
2017-10-26 13:44                       ` Linus Walleij
2017-10-26 13:44                         ` Linus Walleij
2017-10-02 14:09       ` Linus Walleij
2017-10-02 14:09         ` Linus Walleij
2017-10-03  6:30         ` Adrian Hunter
2017-10-03  6:30           ` Adrian Hunter
2017-10-04  7:53           ` Linus Walleij
2017-10-04  7:53             ` Linus Walleij
2017-10-04  8:01             ` Ulf Hansson
2017-10-04  8:01               ` Ulf Hansson
2017-10-02 14:44     ` Michal Hocko
2017-10-02 14:44       ` Michal Hocko
2017-10-02 14:55       ` Tetsuo Handa
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=72c93a69-610f-027e-c028-379b97b6f388@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.