* 4.13 on thinkpad x220: oops when writing to SD card @ 2017-09-05 19:47 Pavel Machek 2017-09-06 2:44 ` Shawn Lin 2017-10-01 9:37 ` 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek 0 siblings, 2 replies; 49+ messages in thread From: Pavel Machek @ 2017-09-05 19:47 UTC (permalink / raw) To: kernel list, adrian.hunter, linux-mmc [-- Attachment #1: Type: text/plain, Size: 3557 bytes --] Hi! I tried to write to the MMC card; process hung and I got this in the dmesg. [15909.353822] usb 2-1.2: Product: Ethernet Gadget [15909.353826] usb 2-1.2: Manufacturer: Linux 4.12.0-03002-gec979a4-dirty with musb-hdrc [15909.362182] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at usb-0000:00:1d.0-1.2, CDC Ethernet Device, e2:f7:c0:44:db:77 [16109.316302] perf: interrupt took too long (2544 > 2500), lowering kernel.perf_event_max_sample_rate to 78500 [18273.845406] mmc0: error -123 whilst initialising SD card [18275.327982] mmc0: new high speed SDHC card at address 0003 [18275.328962] mmcblk0: mmc0:0003 SB08G 7.21 GiB [18275.333698] mmcblk0: p1 p2 p3 [18275.955293] EXT4-fs (mmcblk0p3): mounting ext3 file system using the ext4 subsystem [18276.013021] EXT4-fs (mmcblk0p3): recovery complete [18276.016185] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null) [18306.524676] mmcblk0: p1 p2 p3 [18439.780298] perf: interrupt took too long (3258 > 3180), lowering kernel.perf_event_max_sample_rate to 61250 [19137.696497] perf: interrupt took too long (4082 > 4072), lowering kernel.perf_event_max_sample_rate to 49000 [19925.945831] general protection fault: 0000 [#1] SMP [19925.945909] Modules linked in: [19925.945940] CPU: 2 PID: 30540 Comm: mmcqd/0 Not tainted 4.13.0 #123 [19925.946010] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET73WW (1.43 ) 10/12/2016 [19925.946168] task: ffff88001de9e800 task.stack: ffffc900087d4000 [19925.946293] RIP: 0010:blk_rq_map_sg+0x21a/0x4a3 [19925.946376] RSP: 0000:ffffc900087d7d10 EFLAGS: 00010202 [19925.946479] RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000002000 RCX: 0000000000002000 [19925.946622] RDX: 6b6b6b6b6b6b6b6b RSI: 000000006eed2000 RDI: ffff88009e32b9e0 [19925.946767] RBP: ffffc900087d7d68 R08: 0000000000000000 R09: 0000000063188000 [19925.946919] R10: 0000160000000000 R11: 6db6db6db6db6db7 R12: 0000000000000000 [19925.947059] R13: 0000000000001000 R14: 0000000000000002 R15: ffffea00015ad5c0 [19925.947197] FS: 0000000000000000(0000) GS:ffff88019e280000(0000) knlGS:0000000000000000 [19925.947347] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [19925.947454] CR2: 000000004482a000 CR3: 000000000521d000 CR4: 00000000000406a0 [19925.947586] Call Trace: [19925.947634] mmc_queue_map_sg+0x2f/0xa3 [19925.947703] mmc_blk_rw_rq_prep+0x1fa/0x3d8 [19925.947777] mmc_blk_issue_rw_rq+0xe8/0x419 [19925.947852] mmc_blk_issue_rq+0x589/0x6e7 [19925.947924] mmc_queue_thread+0xe1/0x175 [19925.947996] kthread+0x13d/0x145 [19925.948050] ? mmc_blk_issue_rq+0x6e7/0x6e7 [19925.948125] ? kthread_bind+0x2c/0x2c [19925.948191] ? do_int80_syscall_32+0x5c/0xb4 [19925.948269] ? SyS_exit_group+0xf/0xf [19925.948337] ret_from_fork+0x22/0x30 [19925.948394] Code: 89 e8 4a 8d 74 06 ff 48 09 f7 48 39 fa 75 05 89 48 0c eb 39 48 85 c0 74 0e 48 83 20 fd 48 89 c7 e8 83 02 02 00 eb 04 48 8b 45 b0 <48> 8b 10 83 e2 03 41 f6 c7 03 74 02 0f 0b 4c 09 fa 48 89 10 8b [19925.948980] RIP: blk_rq_map_sg+0x21a/0x4a3 RSP: ffffc900087d7d10 [19925.958464] ---[ end trace 3ddfa379837fe00b ]--- pavel@duo:~$ uname -a Linux duo 4.13.0 #123 SMP Mon Sep 4 10:42:23 CEST 2017 x86_64 GNU/Linux pavel@duo:~$ Similar crash happened yesterday, but that time I got panic (blinking capslock) and stripes on screen. I did not use MMC before. Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 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-10-01 9:37 ` 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek 1 sibling, 1 reply; 49+ messages in thread From: Shawn Lin @ 2017-09-06 2:44 UTC (permalink / raw) To: Pavel Machek, linux-mmc Cc: kernel list, adrian.hunter, shawn.lin, Seraphime Kirkovski + Seraphime On 2017/9/6 3:47, Pavel Machek wrote: > Hi! > > I tried to write to the MMC card; process hung and I got this in the > dmesg. A similar report for 4.13 cycle was here: https://lkml.org/lkml/2017/8/10/824 Seems 4.13-rc4 was already broken for that but unfortuantely I didn't reproduce that. So maybe Seraphime can do git-bisect as he said "I get it everytime" for which I assume it could be easy for him to find out the problematic commit? > > [15909.353822] usb 2-1.2: Product: Ethernet Gadget > [15909.353826] usb 2-1.2: Manufacturer: Linux > 4.12.0-03002-gec979a4-dirty with musb-hdrc > [15909.362182] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > usb-0000:00:1d.0-1.2, CDC Ethernet Device, e2:f7:c0:44:db:77 > [16109.316302] perf: interrupt took too long (2544 > 2500), lowering > kernel.perf_event_max_sample_rate to 78500 > [18273.845406] mmc0: error -123 whilst initialising SD card > [18275.327982] mmc0: new high speed SDHC card at address 0003 > [18275.328962] mmcblk0: mmc0:0003 SB08G 7.21 GiB > [18275.333698] mmcblk0: p1 p2 p3 > [18275.955293] EXT4-fs (mmcblk0p3): mounting ext3 file system using > the ext4 subsystem > [18276.013021] EXT4-fs (mmcblk0p3): recovery complete > [18276.016185] EXT4-fs (mmcblk0p3): mounted filesystem with ordered > data mode. Opts: (null) > [18306.524676] mmcblk0: p1 p2 p3 > [18439.780298] perf: interrupt took too long (3258 > 3180), lowering > kernel.perf_event_max_sample_rate to 61250 > [19137.696497] perf: interrupt took too long (4082 > 4072), lowering > kernel.perf_event_max_sample_rate to 49000 > [19925.945831] general protection fault: 0000 [#1] SMP > [19925.945909] Modules linked in: > [19925.945940] CPU: 2 PID: 30540 Comm: mmcqd/0 Not tainted 4.13.0 #123 > [19925.946010] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET73WW > (1.43 ) 10/12/2016 > [19925.946168] task: ffff88001de9e800 task.stack: ffffc900087d4000 > [19925.946293] RIP: 0010:blk_rq_map_sg+0x21a/0x4a3 > [19925.946376] RSP: 0000:ffffc900087d7d10 EFLAGS: 00010202 > [19925.946479] RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000002000 RCX: > 0000000000002000 > [19925.946622] RDX: 6b6b6b6b6b6b6b6b RSI: 000000006eed2000 RDI: > ffff88009e32b9e0 > [19925.946767] RBP: ffffc900087d7d68 R08: 0000000000000000 R09: > 0000000063188000 > [19925.946919] R10: 0000160000000000 R11: 6db6db6db6db6db7 R12: > 0000000000000000 > [19925.947059] R13: 0000000000001000 R14: 0000000000000002 R15: > ffffea00015ad5c0 > [19925.947197] FS: 0000000000000000(0000) GS:ffff88019e280000(0000) > knlGS:0000000000000000 > [19925.947347] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [19925.947454] CR2: 000000004482a000 CR3: 000000000521d000 CR4: > 00000000000406a0 > [19925.947586] Call Trace: > [19925.947634] mmc_queue_map_sg+0x2f/0xa3 > [19925.947703] mmc_blk_rw_rq_prep+0x1fa/0x3d8 > [19925.947777] mmc_blk_issue_rw_rq+0xe8/0x419 > [19925.947852] mmc_blk_issue_rq+0x589/0x6e7 > [19925.947924] mmc_queue_thread+0xe1/0x175 > [19925.947996] kthread+0x13d/0x145 > [19925.948050] ? mmc_blk_issue_rq+0x6e7/0x6e7 > [19925.948125] ? kthread_bind+0x2c/0x2c > [19925.948191] ? do_int80_syscall_32+0x5c/0xb4 > [19925.948269] ? SyS_exit_group+0xf/0xf > [19925.948337] ret_from_fork+0x22/0x30 > [19925.948394] Code: 89 e8 4a 8d 74 06 ff 48 09 f7 48 39 fa 75 05 89 > 48 0c eb 39 48 85 c0 74 0e 48 83 20 fd 48 89 c7 e8 83 02 02 00 eb 04 > 48 8b 45 b0 <48> 8b 10 83 e2 03 41 f6 c7 03 74 02 0f 0b 4c 09 fa 48 89 > 10 8b > [19925.948980] RIP: blk_rq_map_sg+0x21a/0x4a3 RSP: ffffc900087d7d10 > [19925.958464] ---[ end trace 3ddfa379837fe00b ]--- > pavel@duo:~$ uname -a > Linux duo 4.13.0 #123 SMP Mon Sep 4 10:42:23 CEST 2017 x86_64 > GNU/Linux > pavel@duo:~$ > > Similar crash happened yesterday, but that time I got panic (blinking > capslock) and stripes on screen. I did not use MMC before. > > Any ideas? > > Thanks, > Pavel > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-06 2:44 ` Shawn Lin @ 2017-09-06 6:03 ` Adrian Hunter 2017-09-07 7:18 ` Ulf Hansson 0 siblings, 1 reply; 49+ messages in thread From: Adrian Hunter @ 2017-09-06 6:03 UTC (permalink / raw) To: Shawn Lin, Pavel Machek, linux-mmc; +Cc: kernel list, Seraphime Kirkovski On 06/09/17 05:44, Shawn Lin wrote: > + Seraphime > > On 2017/9/6 3:47, Pavel Machek wrote: >> Hi! >> >> I tried to write to the MMC card; process hung and I got this in the >> dmesg. > > > A similar report for 4.13 cycle was here: > > https://lkml.org/lkml/2017/8/10/824 > > Seems 4.13-rc4 was already broken for that but unfortuantely I didn't > reproduce that. So maybe Seraphime can do git-bisect as he said "I get > it everytime" for which I assume it could be easy for him to find out > the problematic commit? > One obvious weakness in the new mmc_init_request() is the possibility that it might be called before card->bouncesz is set up. That could result in bouncing being done but mq_rq->bounce_sg is null. This might help: diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c index affa7370ba82..ad3e53e63abb 100644 --- a/drivers/mmc/core/queue.c +++ b/drivers/mmc/core/queue.c @@ -242,6 +242,8 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask) limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT; + card->bouncesz = mmc_queue_calc_bouncesz(host); + mq->card = card; mq->queue = blk_alloc_queue(GFP_KERNEL); if (!mq->queue) @@ -265,7 +267,6 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, if (mmc_can_erase(card)) mmc_queue_setup_discard(mq->queue, card); - card->bouncesz = mmc_queue_calc_bouncesz(host); if (card->bouncesz) { blk_queue_max_hw_sectors(mq->queue, card->bouncesz / 512); blk_queue_max_segments(mq->queue, card->bouncesz / 512); Another unrelated issue with mmc_init_request() is that mmc_exit_request() is not called if mmc_init_request() fails, which means mmc_init_request() must free anything it allocates when it fails. ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-06 6:03 ` Adrian Hunter @ 2017-09-07 7:18 ` Ulf Hansson 2017-09-07 7:53 ` Adrian Hunter 2017-09-07 20:02 ` Linus Walleij 0 siblings, 2 replies; 49+ messages in thread From: Ulf Hansson @ 2017-09-07 7:18 UTC (permalink / raw) To: Adrian Hunter Cc: Shawn Lin, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski, Linus Walleij + Linus On 6 September 2017 at 08:03, Adrian Hunter <adrian.hunter@intel.com> wrote: > On 06/09/17 05:44, Shawn Lin wrote: >> + Seraphime >> >> On 2017/9/6 3:47, Pavel Machek wrote: >>> Hi! >>> >>> I tried to write to the MMC card; process hung and I got this in the >>> dmesg. >> >> >> A similar report for 4.13 cycle was here: >> >> https://lkml.org/lkml/2017/8/10/824 >> >> Seems 4.13-rc4 was already broken for that but unfortuantely I didn't >> reproduce that. So maybe Seraphime can do git-bisect as he said "I get >> it everytime" for which I assume it could be easy for him to find out >> the problematic commit? >> > > One obvious weakness in the new mmc_init_request() is the possibility > that it might be called before card->bouncesz is set up. That could > result in bouncing being done but mq_rq->bounce_sg is null. > This might help: > > > diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c > index affa7370ba82..ad3e53e63abb 100644 > --- a/drivers/mmc/core/queue.c > +++ b/drivers/mmc/core/queue.c > @@ -242,6 +242,8 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, > if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask) > limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT; > > + card->bouncesz = mmc_queue_calc_bouncesz(host); > + > mq->card = card; > mq->queue = blk_alloc_queue(GFP_KERNEL); > if (!mq->queue) > @@ -265,7 +267,6 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, > if (mmc_can_erase(card)) > mmc_queue_setup_discard(mq->queue, card); > > - card->bouncesz = mmc_queue_calc_bouncesz(host); > if (card->bouncesz) { > blk_queue_max_hw_sectors(mq->queue, card->bouncesz / 512); > blk_queue_max_segments(mq->queue, card->bouncesz / 512); > Even if this fixes the problem it seems like we are papering over the real issue, which earlier fixes also did during the release cycle for v4.13. Anyway I am happy to apply this as fix for 4.14, if Seraphime/Pavel can report it solved the problem. Could you send a proper patch with some changlog please? I would also appreciate if can add you a small comment in the code, why moving this line is needed. > > Another unrelated issue with mmc_init_request() is that mmc_exit_request() > is not called if mmc_init_request() fails, which means mmc_init_request() > must free anything it allocates when it fails. Yes, the situations it's just too fragile. We need to fix the behavior properly, although I haven't myself been able to investigate exactly how yet. Adding, Linus, perhaps he has some ideas. Kind regards Uffe ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 7:18 ` Ulf Hansson @ 2017-09-07 7:53 ` Adrian Hunter 2017-09-07 10:47 ` Seraphime Kirkovski ` (2 more replies) 2017-09-07 20:02 ` Linus Walleij 1 sibling, 3 replies; 49+ messages in thread From: Adrian Hunter @ 2017-09-07 7:53 UTC (permalink / raw) To: Ulf Hansson Cc: Shawn Lin, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski, Linus Walleij On 07/09/17 10:18, Ulf Hansson wrote: > + Linus > > On 6 September 2017 at 08:03, Adrian Hunter <adrian.hunter@intel.com> wrote: >> On 06/09/17 05:44, Shawn Lin wrote: >>> + Seraphime >>> >>> On 2017/9/6 3:47, Pavel Machek wrote: >>>> Hi! >>>> >>>> I tried to write to the MMC card; process hung and I got this in the >>>> dmesg. >>> >>> >>> A similar report for 4.13 cycle was here: >>> >>> https://lkml.org/lkml/2017/8/10/824 >>> >>> Seems 4.13-rc4 was already broken for that but unfortuantely I didn't >>> reproduce that. So maybe Seraphime can do git-bisect as he said "I get >>> it everytime" for which I assume it could be easy for him to find out >>> the problematic commit? >>> >> >> One obvious weakness in the new mmc_init_request() is the possibility >> that it might be called before card->bouncesz is set up. That could >> result in bouncing being done but mq_rq->bounce_sg is null. >> This might help: >> >> >> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c >> index affa7370ba82..ad3e53e63abb 100644 >> --- a/drivers/mmc/core/queue.c >> +++ b/drivers/mmc/core/queue.c >> @@ -242,6 +242,8 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, >> if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask) >> limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT; >> >> + card->bouncesz = mmc_queue_calc_bouncesz(host); >> + >> mq->card = card; >> mq->queue = blk_alloc_queue(GFP_KERNEL); >> if (!mq->queue) >> @@ -265,7 +267,6 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, >> if (mmc_can_erase(card)) >> mmc_queue_setup_discard(mq->queue, card); >> >> - card->bouncesz = mmc_queue_calc_bouncesz(host); >> if (card->bouncesz) { >> blk_queue_max_hw_sectors(mq->queue, card->bouncesz / 512); >> blk_queue_max_segments(mq->queue, card->bouncesz / 512); >> > > Even if this fixes the problem it seems like we are papering over the > real issue, which earlier fixes also did during the release cycle for > v4.13. blk_init_allocated_queue() allocates 1 request for flush and 4 requests for a memory pool. The memory pool requests only get used under memory pressure. That is why the error doesn't come up straight away. > > Anyway I am happy to apply this as fix for 4.14, if Seraphime/Pavel > can report it solved the problem. Could you send a proper patch with > some changlog please? > > I would also appreciate if can add you a small comment in the code, > why moving this line is needed. From: Adrian Hunter <adrian.hunter@intel.com> Date: Thu, 7 Sep 2017 10:40:35 +0300 Subject: [PATCH] mmc: block: Fix incorrectly initialized requests mmc_init_request() depends on card->bouncesz so it must be calculated before blk_init_allocated_queue() starts allocating requests. Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> --- drivers/mmc/core/queue.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c index affa7370ba82..74c663b1c0a7 100644 --- a/drivers/mmc/core/queue.c +++ b/drivers/mmc/core/queue.c @@ -242,6 +242,12 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask) limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT; + /* + * mmc_init_request() depends on card->bouncesz so it must be calculated + * before blk_init_allocated_queue() starts allocating requests. + */ + card->bouncesz = mmc_queue_calc_bouncesz(host); + mq->card = card; mq->queue = blk_alloc_queue(GFP_KERNEL); if (!mq->queue) @@ -265,7 +271,6 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, if (mmc_can_erase(card)) mmc_queue_setup_discard(mq->queue, card); - card->bouncesz = mmc_queue_calc_bouncesz(host); if (card->bouncesz) { blk_queue_max_hw_sectors(mq->queue, card->bouncesz / 512); blk_queue_max_segments(mq->queue, card->bouncesz / 512); -- 1.9.1 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 7:53 ` Adrian Hunter @ 2017-09-07 10:47 ` Seraphime Kirkovski 2017-09-07 12:06 ` Ulf Hansson 2017-09-07 19:58 ` Linus Walleij 2 siblings, 0 replies; 49+ messages in thread From: Seraphime Kirkovski @ 2017-09-07 10:47 UTC (permalink / raw) To: Adrian Hunter Cc: Ulf Hansson, Shawn Lin, Pavel Machek, linux-mmc, kernel list, Linus Walleij > blk_init_allocated_queue() allocates 1 request for flush and > 4 requests > for a memory pool. The memory pool requests only get used under memory > pressure. That is why the error doesn't come up straight away. This seems correct, I can "trivially" trigger the bug with a while-malloc loop + firefox. > Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> > Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> As I said, this fixes it for me, you can add Tested-By: Seraphime Kirkovski <kirkseraph@gmail.com> Although I'm not sure this covers the same bug Pavel encountered. My kernel doesn't panic, it makes KASAN scream + #GP eventually followed by a lockup. Anyway, thanks for the fix, Seraphime ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 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-08 8:51 ` Pavel Machek 2017-09-07 19:58 ` Linus Walleij 2 siblings, 2 replies; 49+ messages in thread From: Ulf Hansson @ 2017-09-07 12:06 UTC (permalink / raw) To: Adrian Hunter Cc: Shawn Lin, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski, Linus Walleij [...] > > From: Adrian Hunter <adrian.hunter@intel.com> > Date: Thu, 7 Sep 2017 10:40:35 +0300 > Subject: [PATCH] mmc: block: Fix incorrectly initialized requests > > mmc_init_request() depends on card->bouncesz so it must be calculated > before blk_init_allocated_queue() starts allocating requests. > > Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> > Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Thanks, applied for fixes! Kind regards Uffe > --- > drivers/mmc/core/queue.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c > index affa7370ba82..74c663b1c0a7 100644 > --- a/drivers/mmc/core/queue.c > +++ b/drivers/mmc/core/queue.c > @@ -242,6 +242,12 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, > if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask) > limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT; > > + /* > + * mmc_init_request() depends on card->bouncesz so it must be calculated > + * before blk_init_allocated_queue() starts allocating requests. > + */ > + card->bouncesz = mmc_queue_calc_bouncesz(host); > + > mq->card = card; > mq->queue = blk_alloc_queue(GFP_KERNEL); > if (!mq->queue) > @@ -265,7 +271,6 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, > if (mmc_can_erase(card)) > mmc_queue_setup_discard(mq->queue, card); > > - card->bouncesz = mmc_queue_calc_bouncesz(host); > if (card->bouncesz) { > blk_queue_max_hw_sectors(mq->queue, card->bouncesz / 512); > blk_queue_max_segments(mq->queue, card->bouncesz / 512); > -- > 1.9.1 > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 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 1 sibling, 1 reply; 49+ messages in thread From: Pavel Machek @ 2017-09-07 12:55 UTC (permalink / raw) To: Ulf Hansson Cc: Adrian Hunter, Shawn Lin, linux-mmc, kernel list, Seraphime Kirkovski, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 900 bytes --] On Thu 2017-09-07 14:06:52, Ulf Hansson wrote: > [...] > > > > > From: Adrian Hunter <adrian.hunter@intel.com> > > Date: Thu, 7 Sep 2017 10:40:35 +0300 > > Subject: [PATCH] mmc: block: Fix incorrectly initialized requests > > > > mmc_init_request() depends on card->bouncesz so it must be calculated > > before blk_init_allocated_queue() starts allocating requests. > > > > Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> > > Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") > > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> > > Thanks, applied for fixes! Thanks. I believe this one should get cc: stable markups, so eventually 4.13 does get fixed, too.... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 12:55 ` Pavel Machek @ 2017-09-07 15:03 ` Ulf Hansson 0 siblings, 0 replies; 49+ messages in thread From: Ulf Hansson @ 2017-09-07 15:03 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Shawn Lin, linux-mmc, kernel list, Seraphime Kirkovski, Linus Walleij On 7 September 2017 at 14:55, Pavel Machek <pavel@ucw.cz> wrote: > On Thu 2017-09-07 14:06:52, Ulf Hansson wrote: >> [...] >> >> > >> > From: Adrian Hunter <adrian.hunter@intel.com> >> > Date: Thu, 7 Sep 2017 10:40:35 +0300 >> > Subject: [PATCH] mmc: block: Fix incorrectly initialized requests >> > >> > mmc_init_request() depends on card->bouncesz so it must be calculated >> > before blk_init_allocated_queue() starts allocating requests. >> > >> > Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> >> > Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") >> > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> >> >> Thanks, applied for fixes! > > Thanks. I believe this one should get cc: stable markups, so > eventually 4.13 does get fixed, too.... > Pavel Yeah, correct and added! Kind regards Uffe ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 12:06 ` Ulf Hansson 2017-09-07 12:55 ` Pavel Machek @ 2017-09-08 8:51 ` Pavel Machek 1 sibling, 0 replies; 49+ messages in thread From: Pavel Machek @ 2017-09-08 8:51 UTC (permalink / raw) To: Ulf Hansson Cc: Adrian Hunter, Shawn Lin, linux-mmc, kernel list, Seraphime Kirkovski, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 839 bytes --] On Thu 2017-09-07 14:06:52, Ulf Hansson wrote: > [...] > > > > > From: Adrian Hunter <adrian.hunter@intel.com> > > Date: Thu, 7 Sep 2017 10:40:35 +0300 > > Subject: [PATCH] mmc: block: Fix incorrectly initialized requests > > > > mmc_init_request() depends on card->bouncesz so it must be calculated > > before blk_init_allocated_queue() starts allocating requests. > > > > Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> > > Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") > > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> > > Thanks, applied for fixes! Tested-by: Pavel Machek <pavel@ucw.cz> Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 7:53 ` Adrian Hunter 2017-09-07 10:47 ` Seraphime Kirkovski 2017-09-07 12:06 ` Ulf Hansson @ 2017-09-07 19:58 ` Linus Walleij 2 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-09-07 19:58 UTC (permalink / raw) To: Adrian Hunter Cc: Ulf Hansson, Shawn Lin, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski On Thu, Sep 7, 2017 at 9:53 AM, Adrian Hunter <adrian.hunter@intel.com> wrote: > From: Adrian Hunter <adrian.hunter@intel.com> > Date: Thu, 7 Sep 2017 10:40:35 +0300 > Subject: [PATCH] mmc: block: Fix incorrectly initialized requests > > mmc_init_request() depends on card->bouncesz so it must be calculated > before blk_init_allocated_queue() starts allocating requests. > > Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> > Fixes: 304419d8a7e92 ("mmc: core: Allocate per-request data using the block layer core") > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Really neat and quick fix, thanks a lot Adrian. My fault for not finding more systems actually *using* these bounce buffers. :( :( Yours, Linus Walleij ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 7:18 ` Ulf Hansson 2017-09-07 7:53 ` Adrian Hunter @ 2017-09-07 20:02 ` Linus Walleij 2017-09-08 2:51 ` Shawn Lin 1 sibling, 1 reply; 49+ messages in thread From: Linus Walleij @ 2017-09-07 20:02 UTC (permalink / raw) To: Ulf Hansson Cc: Adrian Hunter, Shawn Lin, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski On Thu, Sep 7, 2017 at 9:18 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > Even if this fixes the problem it seems like we are papering over the > real issue, which earlier fixes also did during the release cycle for > v4.13. I think this is the real solution to the issue. >> Another unrelated issue with mmc_init_request() is that mmc_exit_request() >> is not called if mmc_init_request() fails, which means mmc_init_request() >> must free anything it allocates when it fails. > > Yes, the situations it's just too fragile. We need to fix the behavior > properly, although I haven't myself been able to investigate exactly > how yet. > > Adding, Linus, perhaps he has some ideas. Maybe we should simply bite the bullet and do what was suggested by another contributor when I refactored the bounce buffer handling: simply delete the bounce buffer code and let any remaining (few?) legacy devices suffer a bit (performancewise) at the gain of way simpler code? I am a bit hesitant about that because Pierre Ossman said it was actually a big win on the SDHC hosts that made use of it at one point. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-07 20:02 ` Linus Walleij @ 2017-09-08 2:51 ` Shawn Lin 2017-09-12 9:42 ` Linus Walleij 0 siblings, 1 reply; 49+ messages in thread From: Shawn Lin @ 2017-09-08 2:51 UTC (permalink / raw) To: Linus Walleij, Ulf Hansson Cc: shawn.lin, Adrian Hunter, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski On 2017/9/8 4:02, Linus Walleij wrote: > On Thu, Sep 7, 2017 at 9:18 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > >> Even if this fixes the problem it seems like we are papering over the >> real issue, which earlier fixes also did during the release cycle for >> v4.13. > > I think this is the real solution to the issue. > >>> Another unrelated issue with mmc_init_request() is that mmc_exit_request() >>> is not called if mmc_init_request() fails, which means mmc_init_request() >>> must free anything it allocates when it fails. >> >> Yes, the situations it's just too fragile. We need to fix the behavior >> properly, although I haven't myself been able to investigate exactly >> how yet. >> >> Adding, Linus, perhaps he has some ideas. > > Maybe we should simply bite the bullet and do what was suggested > by another contributor when I refactored the bounce buffer handling: > simply delete the bounce buffer code and let any remaining (few?) > legacy devices suffer a bit (performancewise) at the gain of way > simpler code? Are you in the same page with what Adrian pointed to? IIUC, the issue is: init_rq_fn will be called each time when trying to create new reuqest from the pre-allocated request_list memeory pool, and exit_rq_fn will is in the corresponding routine to free request from request_list (blk_free_request) when finished. But if alloc_request_size fails, it won't call exit_rq_fn, so you need to prevent memory leak on your own error path of init_rq_fn. But you seem to talk about removing the bounce buffer and so finally get rid of registering init_rq_fn/exit_rq_fn? That is another thing, and what we right now need to do is to fix the pontential memory leak. It's quite a simple action, right? :) > > I am a bit hesitant about that because Pierre Ossman said it was > actually a big win on the SDHC hosts that made use of it at one > point. You had removed packed cmd support to simplify the code, so I think this is another trade-off need to ask: What you want? and keep consistent with the direction you insisted on. > > Yours, > Linus Walleij > > > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-08 2:51 ` Shawn Lin @ 2017-09-12 9:42 ` Linus Walleij 2017-09-13 4:04 ` Shawn Lin 0 siblings, 1 reply; 49+ messages in thread From: Linus Walleij @ 2017-09-12 9:42 UTC (permalink / raw) To: Shawn Lin Cc: Ulf Hansson, Adrian Hunter, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski On Fri, Sep 8, 2017 at 4:51 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote: > On 2017/9/8 4:02, Linus Walleij wrote: >> On Thu, Sep 7, 2017 at 9:18 AM, Ulf Hansson <ulf.hansson@linaro.org> >> wrote: >> >>> Even if this fixes the problem it seems like we are papering over the >>> real issue, which earlier fixes also did during the release cycle for >>> v4.13. >> >> >> I think this is the real solution to the issue. >> >>>> Another unrelated issue with mmc_init_request() is that >>>> mmc_exit_request() >>>> is not called if mmc_init_request() fails, which means >>>> mmc_init_request() >>>> must free anything it allocates when it fails. >>> >>> >>> Yes, the situations it's just too fragile. We need to fix the behavior >>> properly, although I haven't myself been able to investigate exactly >>> how yet. >>> >>> Adding, Linus, perhaps he has some ideas. >> >> >> Maybe we should simply bite the bullet and do what was suggested >> by another contributor when I refactored the bounce buffer handling: >> simply delete the bounce buffer code and let any remaining (few?) >> legacy devices suffer a bit (performancewise) at the gain of way >> simpler code? > > Are you in the same page with what Adrian pointed to? > > IIUC, the issue is: > init_rq_fn will be called each time when trying to create new reuqest > from the pre-allocated request_list memeory pool, and exit_rq_fn will is > in the corresponding routine to free request from request_list > (blk_free_request) when finished. But if alloc_request_size fails, it > won't call exit_rq_fn, so you need to prevent memory leak on your own > error path of init_rq_fn. Yes and that is what the current patch fixes, is it not? > But you seem to talk about removing the bounce buffer and so finally > get rid of registering init_rq_fn/exit_rq_fn? That is in direct response to Ulf's statement "the situations it's just too fragile" and what can be done about that is not make the code even more complex but make it simpler and easier to follow. One way to achieve that in the long term, is to delete bounce buffer handling since it adds overhead and complexity. > That is another thing, > and what we right now need to do is to fix the pontential memory leak. > It's quite a simple action, right? :) It is another thing. This patch fixes a memory leak, but Ulf is asking how we may avoid fragile behaviour. >> I am a bit hesitant about that because Pierre Ossman said it was >> actually a big win on the SDHC hosts that made use of it at one >> point. > > You had removed packed cmd support to simplify the code, so I think > this is another trade-off need to ask: What you want? and keep > consistent with the direction you insisted on. Packed command could be removed because it was not used by any in-tree code. See commit 03d640ae1f9b24b1d2a11f747143a1ecc0745019 Bounce buffers on the other hand, as this patch shows, is very much in use. So if they e.g. improve throughput on these systems (mainly laptops I think?) it should definately be kept around. It might be a good idea to make a patch to remove the bounce buffers and ask people to do before/after throughput tests, because I do not have this hardware myself. If it doesn't provide any throughput improvements to any system in use, it should be deleted. But I don't know that yet. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.13 on thinkpad x220: oops when writing to SD card 2017-09-12 9:42 ` Linus Walleij @ 2017-09-13 4:04 ` Shawn Lin 0 siblings, 0 replies; 49+ messages in thread From: Shawn Lin @ 2017-09-13 4:04 UTC (permalink / raw) To: Linus Walleij Cc: shawn.lin, Ulf Hansson, Adrian Hunter, Pavel Machek, linux-mmc, kernel list, Seraphime Kirkovski On 2017/9/12 17:42, Linus Walleij wrote: > On Fri, Sep 8, 2017 at 4:51 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote: >> On 2017/9/8 4:02, Linus Walleij wrote: >>> On Thu, Sep 7, 2017 at 9:18 AM, Ulf Hansson <ulf.hansson@linaro.org> >>> wrote: >>> >>>> Even if this fixes the problem it seems like we are papering over the >>>> real issue, which earlier fixes also did during the release cycle for >>>> v4.13. >>> >>> >>> I think this is the real solution to the issue. >>> >>>>> Another unrelated issue with mmc_init_request() is that >>>>> mmc_exit_request() >>>>> is not called if mmc_init_request() fails, which means >>>>> mmc_init_request() >>>>> must free anything it allocates when it fails. >>>> >>>> >>>> Yes, the situations it's just too fragile. We need to fix the behavior >>>> properly, although I haven't myself been able to investigate exactly >>>> how yet. >>>> >>>> Adding, Linus, perhaps he has some ideas. >>> >>> >>> Maybe we should simply bite the bullet and do what was suggested >>> by another contributor when I refactored the bounce buffer handling: >>> simply delete the bounce buffer code and let any remaining (few?) >>> legacy devices suffer a bit (performancewise) at the gain of way >>> simpler code? >> >> Are you in the same page with what Adrian pointed to? >> >> IIUC, the issue is: >> init_rq_fn will be called each time when trying to create new reuqest >> from the pre-allocated request_list memeory pool, and exit_rq_fn will is >> in the corresponding routine to free request from request_list >> (blk_free_request) when finished. But if alloc_request_size fails, it >> won't call exit_rq_fn, so you need to prevent memory leak on your own >> error path of init_rq_fn. > > Yes and that is what the current patch fixes, is it not? Nope. It fixed the *out-of-bound* memory usage as request queue will hold 4 requests by default and only use these four requests when meeting memory pressure. But the code didn't place the correct bouncesz so that the 4 pre-allocated requests didn't have valid memory page when allocated. But in runtime, normally the request queue asks for new request from request list by dynamically allocating it. So your init_rq_fn will be called each time. However the mmc_init_request didn't handle the error path properly。 I simply add SDHCI_QUIRK_BROKEN_ADMA for my SDHCI to force it use SDMA so that the host->max_segs should be 1. Then add some a hack to simulate some random failure for mmc_alloc_sg and then after some iozone stress test, the memory is exhausted finally. +static u64 skip = 0; static struct scatterlist *mmc_alloc_sg(int sg_len, gfp_t gfp) { struct scatterlist *sg; + u32 random = 0; + + /* Simply skip the bootup stage */ + if (skip++ >= 0x800) + random = get_random_int(); + + if (unlikely((random & 0xf) > 0xd)) { + printk("mmc_alloc_sg: make fake failure, random = 0x%x\n", random); + return NULL; + } [ 540.507195] iozone invoked oom-killer: gfp_mask=0x16040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=0 [ 540.508302] iozone cpuset=/ mems_allowed=0 [ 540.508727] CPU: 2 PID: 3039 Comm: iozone Not tainted 4.13.0-next-20170912-00003-g01cc0dd5-dirty #110 [ 540.509537] Hardware name: Firefly-RK3399 Board (DT) [ 540.509977] Call trace: [ 540.510221] [<ffff20000808b3d0>] dump_backtrace+0x0/0x480 [ 540.510707] [<ffff20000808b864>] show_stack+0x14/0x20 [ 540.511164] [<ffff200008dfbabc>] dump_stack+0xa4/0xc8 [ 540.511621] [<ffff2000081fc744>] dump_header+0xc4/0x2e8 [ 540.512091] [<ffff2000081fb888>] oom_kill_process+0x3a8/0x728 [ 540.512605] [<ffff2000081fc090>] out_of_memory+0x1a8/0x6d8 [ 540.513099] [<ffff200008203ea8>] __alloc_pages_nodemask+0xef8/0xf80 [ 540.513660] [<ffff200008275d6c>] alloc_pages_current+0x9c/0x128 [ 540.514191] [<ffff200008281f60>] new_slab+0x488/0x5d8 [ 540.514645] [<ffff200008284198>] ___slab_alloc+0x378/0x5d0 [ 540.515138] [<ffff200008284414>] __slab_alloc.isra.23+0x24/0x38 [ 540.515668] [<ffff200008284d44>] kmem_cache_alloc+0x1ec/0x218 [ 540.516183] [<ffff20000830dc30>] __blockdev_direct_IO+0x220/0x4a00 > >> But you seem to talk about removing the bounce buffer and so finally >> get rid of registering init_rq_fn/exit_rq_fn? > > That is in direct response to Ulf's statement > "the situations it's just too fragile" and what can be done about > that is not make the code even more complex but make it > simpler and easier to follow. > > One way to achieve that in the long term, is to delete bounce > buffer handling since it adds overhead and complexity. > >> That is another thing, >> and what we right now need to do is to fix the pontential memory leak. >> It's quite a simple action, right? :) > > It is another thing. > > This patch fixes a memory leak, but Ulf is asking how we may > avoid fragile behaviour. > >>> I am a bit hesitant about that because Pierre Ossman said it was >>> actually a big win on the SDHC hosts that made use of it at one >>> point. >> >> You had removed packed cmd support to simplify the code, so I think >> this is another trade-off need to ask: What you want? and keep >> consistent with the direction you insisted on. > > Packed command could be removed because it was not used by > any in-tree code. See > commit 03d640ae1f9b24b1d2a11f747143a1ecc0745019 > Ok, I was surprised that no any in-tree host enabled it, but if some host did, the situation was similar with this one. > Bounce buffers on the other hand, as this patch shows, is very much > in use. So if they e.g. improve throughput on these systems > (mainly laptops I think?) it should definately be kept around. > > It might be a good idea to make a patch to remove the bounce > buffers and ask people to do before/after throughput tests, > because I do not have this hardware myself. If it doesn't provide > any throughput improvements to any system in use, it should > be deleted. But I don't know that yet. yeap, sounds good but it's up to Ulf. > > Yours, > Linus Walleij > > > ^ permalink raw reply [flat|nested] 49+ messages in thread
* 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 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-10-01 9:37 ` Pavel Machek 2017-10-01 10:26 ` Pavel Machek 1 sibling, 1 reply; 49+ messages in thread From: Pavel Machek @ 2017-10-01 9:37 UTC (permalink / raw) To: kernel list, adrian.hunter, linux-mmc [-- Attachment #1: Type: text/plain, Size: 1710 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 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 14:44 ` Michal Hocko 0 siblings, 2 replies; 49+ messages in thread From: Pavel Machek @ 2017-10-01 10:26 UTC (permalink / raw) To: kernel list, adrian.hunter, linux-mmc; +Cc: linux-mm, penguin-kernel [-- Attachment #1: Type: text/plain, Size: 1959 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-01 10:26 ` Pavel Machek @ 2017-10-01 10:57 ` Tetsuo Handa 2017-10-02 14:44 ` Michal Hocko 1 sibling, 0 replies; 49+ messages in thread From: Tetsuo Handa @ 2017-10-01 10:57 UTC (permalink / raw) To: pavel; +Cc: linux-kernel, adrian.hunter, linux-mmc, linux-mm 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-01 10:57 ` Tetsuo Handa 0 siblings, 0 replies; 49+ messages in thread From: Tetsuo Handa @ 2017-10-01 10:57 UTC (permalink / raw) To: pavel; +Cc: linux-kernel, adrian.hunter, linux-mmc, linux-mm 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-01 10:57 ` Tetsuo Handa @ 2017-10-02 7:52 ` Adrian Hunter -1 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-02 7:52 UTC (permalink / raw) To: Tetsuo Handa, pavel; +Cc: linux-kernel, linux-mmc, linux-mm, linus walleij 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 > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-02 7:52 ` Adrian Hunter 0 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-02 7:52 UTC (permalink / raw) To: Tetsuo Handa, pavel; +Cc: linux-kernel, linux-mmc, linux-mm, linus walleij 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-02 7:52 ` Adrian Hunter (?) @ 2017-10-02 8:41 ` Pavel Machek 2017-10-02 12:06 ` Linus Walleij -1 siblings, 1 reply; 49+ messages in thread From: Pavel Machek @ 2017-10-02 8:41 UTC (permalink / raw) To: Adrian Hunter Cc: Tetsuo Handa, linux-kernel, linux-mmc, linux-mm, linus walleij [-- Attachment #1: Type: text/plain, Size: 3889 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-02 8:41 ` Pavel Machek @ 2017-10-02 12:06 ` Linus Walleij 0 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-02 12:06 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-02 12:06 ` Linus Walleij 0 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-02 12:06 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm 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 -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-02 12:06 ` Linus Walleij (?) @ 2017-10-02 13:03 ` Pavel Machek 2017-10-03 6:27 ` Adrian Hunter -1 siblings, 1 reply; 49+ messages in thread From: Pavel Machek @ 2017-10-02 13:03 UTC (permalink / raw) To: Linus Walleij Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm [-- Attachment #1: Type: text/plain, Size: 1044 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-02 13:03 ` Pavel Machek @ 2017-10-03 6:27 ` Adrian Hunter 0 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-03 6:27 UTC (permalink / raw) To: Pavel Machek, Linus Walleij Cc: Tetsuo Handa, linux-kernel, linux-mmc, linux-mm On 02/10/17 16:03, Pavel Machek wrote: > 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. You are certainly using bounce buffers. What does lspci -knn show? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-03 6:27 ` Adrian Hunter 0 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-03 6:27 UTC (permalink / raw) To: Pavel Machek, Linus Walleij Cc: Tetsuo Handa, linux-kernel, linux-mmc, linux-mm On 02/10/17 16:03, Pavel Machek wrote: > 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. You are certainly using bounce buffers. What does lspci -knn show? -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 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 -1 siblings, 2 replies; 49+ messages in thread From: Pavel Machek @ 2017-10-23 9:31 UTC (permalink / raw) To: Adrian Hunter Cc: Linus Walleij, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm [-- Attachment #1: Type: text/plain, Size: 3491 bytes --] Hi! > >> 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. > > You are certainly using bounce buffers. What does lspci -knn show? Here is the output: Pavel 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) Subsystem: Lenovo Device [17aa:21da] 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) Subsystem: Lenovo Device [17aa:21da] Kernel driver in use: i915 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) Subsystem: Lenovo Device [17aa:21da] 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) Subsystem: Lenovo Device [17aa:21ce] Kernel driver in use: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) Subsystem: Lenovo Device [17aa:21da] Kernel driver in use: ehci-pci 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04) Subsystem: Lenovo Device [17aa:21da] Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4) Kernel driver in use: pcieport 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4) Kernel driver in use: pcieport 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4) Kernel driver in use: pcieport 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04) Subsystem: Lenovo Device [17aa:21da] Kernel driver in use: ehci-pci 00:1f.0 ISA bridge [0601]: Intel Corporation QM67 Express Chipset Family LPC Controller [8086:1c4f] (rev 04) Subsystem: Lenovo Device [17aa:21da] 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04) Subsystem: Lenovo Device [17aa:21da] Kernel driver in use: ahci 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04) Subsystem: Lenovo Device [17aa:21da] 03:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 1000 [Condor Peak] [8086:0084] Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN [8086:1315] Kernel driver in use: iwlwifi 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-23 9:31 ` Pavel Machek @ 2017-10-23 12:13 ` Adrian Hunter 2017-10-23 12:16 ` Linus Walleij 1 sibling, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-23 12:13 UTC (permalink / raw) To: Pavel Machek Cc: Linus Walleij, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm On 23/10/17 12:31, Pavel Machek wrote: > Hi! > >>>> 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. >> >> You are certainly using bounce buffers. What does lspci -knn show? > > Here is the output: > Pavel > > 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) > Subsystem: Lenovo Device [17aa:21da] > 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: i915 > 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) > Subsystem: Lenovo Device [17aa:21ce] > Kernel driver in use: e1000e > 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: ehci-pci > 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: snd_hda_intel > 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) > Kernel driver in use: pcieport > 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4) > Kernel driver in use: pcieport > 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4) > Kernel driver in use: pcieport > 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4) > Kernel driver in use: pcieport > 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: ehci-pci > 00:1f.0 ISA bridge [0601]: Intel Corporation QM67 Express Chipset Family LPC Controller [8086:1c4f] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: ahci > 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > 03:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 1000 [Condor Peak] [8086:0084] > Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN [8086:1315] > Kernel driver in use: iwlwifi > 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 Yes, the code for Ricoh in sdhci-pci specifies only SDMA which means no scatter-gather. That might benefit from bounce buffers, but it seems like the memory allocation was silently failing anyway if a card was inserted after memory has fragmented. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-23 12:13 ` Adrian Hunter 0 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-23 12:13 UTC (permalink / raw) To: Pavel Machek Cc: Linus Walleij, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm On 23/10/17 12:31, Pavel Machek wrote: > Hi! > >>>> 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. >> >> You are certainly using bounce buffers. What does lspci -knn show? > > Here is the output: > Pavel > > 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) > Subsystem: Lenovo Device [17aa:21da] > 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: i915 > 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) > Subsystem: Lenovo Device [17aa:21ce] > Kernel driver in use: e1000e > 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: ehci-pci > 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: snd_hda_intel > 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) > Kernel driver in use: pcieport > 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4) > Kernel driver in use: pcieport > 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4) > Kernel driver in use: pcieport > 00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4) > Kernel driver in use: pcieport > 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: ehci-pci > 00:1f.0 ISA bridge [0601]: Intel Corporation QM67 Express Chipset Family LPC Controller [8086:1c4f] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > Kernel driver in use: ahci > 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04) > Subsystem: Lenovo Device [17aa:21da] > 03:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 1000 [Condor Peak] [8086:0084] > Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN [8086:1315] > Kernel driver in use: iwlwifi > 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 Yes, the code for Ricoh in sdhci-pci specifies only SDMA which means no scatter-gather. That might benefit from bounce buffers, but it seems like the memory allocation was silently failing anyway if a card was inserted after memory has fragmented. -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-23 9:31 ` Pavel Machek @ 2017-10-23 12:16 ` Linus Walleij 2017-10-23 12:16 ` Linus Walleij 1 sibling, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-23 12:16 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm 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. I'm now feel it was the right thing to delete them. I assume the problem doesn't appear in later -rc:s am I right? Yours, Linus Walleij ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-23 12:16 ` Linus Walleij 0 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-23 12:16 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm 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. I'm now feel it was the right thing to delete them. I assume the problem doesn't appear in later -rc:s am I right? Yours, Linus Walleij -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 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 -1 siblings, 2 replies; 49+ messages in thread From: Pavel Machek @ 2017-10-23 21:27 UTC (permalink / raw) To: Linus Walleij Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm [-- Attachment #1: Type: text/plain, Size: 1370 bytes --] 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?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-23 21:27 ` Pavel Machek @ 2017-10-24 6:59 ` Adrian Hunter 2017-10-26 13:44 ` Linus Walleij 1 sibling, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-24 6:59 UTC (permalink / raw) To: Pavel Machek, Linus Walleij Cc: Tetsuo Handa, linux-kernel, linux-mmc, linux-mm 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-24 6:59 ` Adrian Hunter 0 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-24 6:59 UTC (permalink / raw) To: Pavel Machek, Linus Walleij Cc: Tetsuo Handa, linux-kernel, linux-mmc, linux-mm 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. -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-23 21:27 ` Pavel Machek @ 2017-10-26 13:44 ` Linus Walleij 2017-10-26 13:44 ` Linus Walleij 1 sibling, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-26 13:44 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm On Mon, Oct 23, 2017 at 11:27 PM, Pavel Machek <pavel@ucw.cz> 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. 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-26 13:44 ` Linus Walleij 0 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-26 13:44 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Hunter, Tetsuo Handa, linux-kernel, linux-mmc, linux-mm On Mon, Oct 23, 2017 at 11:27 PM, Pavel Machek <pavel@ucw.cz> 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. 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@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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-01 10:57 ` Tetsuo Handa @ 2017-10-02 14:09 ` Linus Walleij -1 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-02 14:09 UTC (permalink / raw) To: Tetsuo Handa Cc: Pavel Machek, linux-kernel, Adrian Hunter, linux-mmc, linux-mm 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. Now it happens later, and that fails sometimes apparently. > 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? Using kvmalloc() is against the design of the bounce buffer if that means we allocate virtual (non-contigous) memory. These bounce buffers exist exactly to be contigous. I think it is better to delete the bounce buffer handling altogether since it anyways turns out that noone is using them or getting any benefit from them. AFAICT. i.e. just cherry-pick commit a16a2cc4f37d4a35df7cdc5c976465f9867985c2 ("mmc: Delete bounce buffer handling"). This should be fine to cherry-pick for fixes. What we figured out is that bounce buffers are almost always enabled but very seldom actually used by the drivers. It is only used by drivers with max_segs == 1. This MMC host driver (which one?) appears to be having max_segs == 1. This doesn't mean that the bounce buffers actually provide a speedup. Most probably not. It just happens that code enables them if you have max_segs == 1. Can you try cherry-picking the above patch, also here: https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=next&id=a16a2cc4f37d4a35df7cdc5c976465f9867985c2 And see if this solves your problem? Yours, Linus Walleij ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-02 14:09 ` Linus Walleij 0 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-02 14:09 UTC (permalink / raw) To: Tetsuo Handa Cc: Pavel Machek, linux-kernel, Adrian Hunter, linux-mmc, linux-mm 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. Now it happens later, and that fails sometimes apparently. > 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? Using kvmalloc() is against the design of the bounce buffer if that means we allocate virtual (non-contigous) memory. These bounce buffers exist exactly to be contigous. I think it is better to delete the bounce buffer handling altogether since it anyways turns out that noone is using them or getting any benefit from them. AFAICT. i.e. just cherry-pick commit a16a2cc4f37d4a35df7cdc5c976465f9867985c2 ("mmc: Delete bounce buffer handling"). This should be fine to cherry-pick for fixes. What we figured out is that bounce buffers are almost always enabled but very seldom actually used by the drivers. It is only used by drivers with max_segs == 1. This MMC host driver (which one?) appears to be having max_segs == 1. This doesn't mean that the bounce buffers actually provide a speedup. Most probably not. It just happens that code enables them if you have max_segs == 1. Can you try cherry-picking the above patch, also here: https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=next&id=a16a2cc4f37d4a35df7cdc5c976465f9867985c2 And see if this solves your problem? Yours, Linus Walleij -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-02 14:09 ` Linus Walleij @ 2017-10-03 6:30 ` Adrian Hunter -1 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-03 6:30 UTC (permalink / raw) To: Linus Walleij, Tetsuo Handa Cc: Pavel Machek, linux-kernel, linux-mmc, linux-mm 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-03 6:30 ` Adrian Hunter 0 siblings, 0 replies; 49+ messages in thread From: Adrian Hunter @ 2017-10-03 6:30 UTC (permalink / raw) To: Linus Walleij, Tetsuo Handa Cc: Pavel Machek, linux-kernel, linux-mmc, linux-mm 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 -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-03 6:30 ` Adrian Hunter @ 2017-10-04 7:53 ` Linus Walleij -1 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-04 7:53 UTC (permalink / raw) To: Adrian Hunter Cc: Tetsuo Handa, Pavel Machek, linux-kernel, linux-mmc, linux-mm 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. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-04 7:53 ` Linus Walleij 0 siblings, 0 replies; 49+ messages in thread From: Linus Walleij @ 2017-10-04 7:53 UTC (permalink / raw) To: Adrian Hunter Cc: Tetsuo Handa, Pavel Machek, linux-kernel, linux-mmc, linux-mm 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. Yours, Linus Walleij -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-04 7:53 ` Linus Walleij @ 2017-10-04 8:01 ` Ulf Hansson -1 siblings, 0 replies; 49+ messages in thread From: Ulf Hansson @ 2017-10-04 8:01 UTC (permalink / raw) To: Linus Walleij, Adrian Hunter Cc: Tetsuo Handa, Pavel Machek, linux-kernel, linux-mmc, linux-mm 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-04 8:01 ` Ulf Hansson 0 siblings, 0 replies; 49+ messages in thread From: Ulf Hansson @ 2017-10-04 8:01 UTC (permalink / raw) To: Linus Walleij, Adrian Hunter Cc: Tetsuo Handa, Pavel Machek, linux-kernel, linux-mmc, linux-mm 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 -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-01 10:26 ` Pavel Machek @ 2017-10-02 14:44 ` Michal Hocko 2017-10-02 14:44 ` Michal Hocko 1 sibling, 0 replies; 49+ messages in thread From: Michal Hocko @ 2017-10-02 14:44 UTC (permalink / raw) To: Pavel Machek Cc: kernel list, adrian.hunter, linux-mmc, linux-mm, penguin-kernel On Sun 01-10-17 12:26:47, 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. Well, I cannot comment on why MMC needs such a large allocation and whether it can safely fall back to vmalloc but __GFP_RETRY_MAYFAIL might help to try harder and require compaction to do more work. Relying on that for correctness is, of course, a different story and a very unreliable under memory pressure or long term fragmented memory. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-02 14:44 ` Michal Hocko 0 siblings, 0 replies; 49+ messages in thread From: Michal Hocko @ 2017-10-02 14:44 UTC (permalink / raw) To: Pavel Machek Cc: kernel list, adrian.hunter, linux-mmc, linux-mm, penguin-kernel On Sun 01-10-17 12:26:47, 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. Well, I cannot comment on why MMC needs such a large allocation and whether it can safely fall back to vmalloc but __GFP_RETRY_MAYFAIL might help to try harder and require compaction to do more work. Relying on that for correctness is, of course, a different story and a very unreliable under memory pressure or long term fragmented memory. -- Michal Hocko SUSE Labs -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card 2017-10-02 14:44 ` Michal Hocko @ 2017-10-02 14:55 ` Tetsuo Handa -1 siblings, 0 replies; 49+ messages in thread From: Tetsuo Handa @ 2017-10-02 14:55 UTC (permalink / raw) To: mhocko, pavel; +Cc: linux-kernel, adrian.hunter, linux-mmc, linux-mm Michal Hocko wrote: > On Sun 01-10-17 12:26:47, 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. > > Well, I cannot comment on why MMC needs such a large allocation and > whether it can safely fall back to vmalloc but __GFP_RETRY_MAYFAIL > might help to try harder and require compaction to do more work. > Relying on that for correctness is, of course, a different story and > a very unreliable under memory pressure or long term fragmented memory. Linus Walleij answered that kvmalloc() is against the design of the bounce buffer at http://lkml.kernel.org/r/CACRpkdYirC+rh_KALgVqKZMjq2DgbW4oi9MJkmrzwn+1O+94-g@mail.gmail.com . ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card @ 2017-10-02 14:55 ` Tetsuo Handa 0 siblings, 0 replies; 49+ messages in thread From: Tetsuo Handa @ 2017-10-02 14:55 UTC (permalink / raw) To: mhocko, pavel; +Cc: linux-kernel, adrian.hunter, linux-mmc, linux-mm Michal Hocko wrote: > On Sun 01-10-17 12:26:47, 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. > > Well, I cannot comment on why MMC needs such a large allocation and > whether it can safely fall back to vmalloc but __GFP_RETRY_MAYFAIL > might help to try harder and require compaction to do more work. > Relying on that for correctness is, of course, a different story and > a very unreliable under memory pressure or long term fragmented memory. Linus Walleij answered that kvmalloc() is against the design of the bounce buffer at http://lkml.kernel.org/r/CACRpkdYirC+rh_KALgVqKZMjq2DgbW4oi9MJkmrzwn+1O+94-g@mail.gmail.com . -- 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> ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2017-10-26 13:44 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.