Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1742760 > unrolled thread

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

Started byPavel Machek <pavel@ucw.cz>
First post2017-10-01 11:40 +0200
Last post2017-10-02 15:10 +0200
Articles 7 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek <pavel@ucw.cz> - 2017-10-01 11:40 +0200
    Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek <pavel@ucw.cz> - 2017-10-01 12:30 +0200
      Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-10-01 13:00 +0200
        Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Adrian Hunter <adrian.hunter@intel.com> - 2017-10-02 10:00 +0200
          Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek <pavel@ucw.cz> - 2017-10-02 10:50 +0200
            Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Linus Walleij <linus.walleij@linaro.org> - 2017-10-02 14:10 +0200
              Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek <pavel@ucw.cz> - 2017-10-02 15:10 +0200

#1742760 — 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

FromPavel Machek <pavel@ucw.cz>
Date2017-10-01 11:40 +0200
Subject4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
Message-ID<uvIT7-kr-5@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi!

I inserted u-SD card, only to realize that it is not detected as it
should be. And dmesg indeed reveals:

[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

[toc] | [next] | [standalone]

#1742775

FromPavel Machek <pavel@ucw.cz>
Date2017-10-01 12:30 +0200
Message-ID<uvJFw-Sf-7@gated-at.bofh.it>
In reply to#1742760

[Multipart message — attachments visible in raw view] — view raw

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.

> [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

[toc] | [prev] | [next] | [standalone]

#1742782

FromTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date2017-10-01 13:00 +0200
Message-ID<uvK8y-13T-15@gated-at.bofh.it>
In reply to#1742775
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

[toc] | [prev] | [next] | [standalone]

#1743001

FromAdrian Hunter <adrian.hunter@intel.com>
Date2017-10-02 10:00 +0200
Message-ID<uw3NV-4As-11@gated-at.bofh.it>
In reply to#1742782
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
>

[toc] | [prev] | [next] | [standalone]

#1743024

FromPavel Machek <pavel@ucw.cz>
Date2017-10-02 10:50 +0200
Message-ID<uw4Ah-55v-13@gated-at.bofh.it>
In reply to#1743001

[Multipart message — attachments visible in raw view] — view raw

Hi!

> 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.

At this point, I don't really care about memory leaks.

But allocating 64KiB, and expecting the allocation to work is quite a
big no-no. Does code need to switch to vmalloc or something?

> Bounce buffers are being removed from v4.15 although you may experience
> performance regression with that:
> 
> 	https://marc.info/?l=linux-mmc&m=150589778700551

Hmm. The performance of this is already pretty bad, I really hope it
does not get any worse.

								Pavel

> 
> 
> 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
> > 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1743151

FromLinus Walleij <linus.walleij@linaro.org>
Date2017-10-02 14:10 +0200
Message-ID<uw7HP-77O-7@gated-at.bofh.it>
In reply to#1743024
On Mon, Oct 2, 2017 at 10:41 AM, Pavel Machek <pavel@ucw.cz> wrote:

>> Bounce buffers are being removed from v4.15

As Adrian states, this would make any last bugs go away. I would
even consider putting this patch this into fixes if it solves the problem.

> although you may experience
>> performance regression with that:
>>
>>       https://marc.info/?l=linux-mmc&m=150589778700551
>
> Hmm. The performance of this is already pretty bad, I really hope it
> does not get any worse.

Did you use bounce buffers? Those were improving performance on
some laptops with TI or Ricoh host controllers and nothing else was
ever really using it (as can be seen from the commit).

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1743212

FromPavel Machek <pavel@ucw.cz>
Date2017-10-02 15:10 +0200
Message-ID<uw8DV-7GI-39@gated-at.bofh.it>
In reply to#1743151

[Multipart message — attachments visible in raw view] — view raw

On Mon 2017-10-02 14:06:03, Linus Walleij wrote:
> On Mon, Oct 2, 2017 at 10:41 AM, Pavel Machek <pavel@ucw.cz> wrote:
> 
> >> Bounce buffers are being removed from v4.15
> 
> As Adrian states, this would make any last bugs go away. I would
> even consider putting this patch this into fixes if it solves the problem.
> 
> > although you may experience
> >> performance regression with that:
> >>
> >>       https://marc.info/?l=linux-mmc&m=150589778700551
> >
> > Hmm. The performance of this is already pretty bad, I really hope it
> > does not get any worse.
> 
> Did you use bounce buffers? Those were improving performance on
> some laptops with TI or Ricoh host controllers and nothing else was
> ever really using it (as can be seen from the commit).

Thinkpad X220... how do I tell if I was using them? I believe so,
because I uncovered bug in them before.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web