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

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

[Pavel Machek]

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

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

[Tetsuo Handa]

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>

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

[Adrian Hunter]

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>

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

[Pavel Machek]

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

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

[Linus Walleij]

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>

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

[Pavel Machek]

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

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

[Linus Walleij]

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>

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

[Michal Hocko]

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>

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

[Tetsuo Handa]

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>

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

[Adrian Hunter]

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>

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

[Adrian Hunter]

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>

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

[Linus Walleij]

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>

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

[Ulf Hansson]

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>

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

[Pavel Machek]

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

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

[Adrian Hunter]

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>

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

[Linus Walleij]

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>

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

[Pavel Machek]

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

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

[Adrian Hunter]

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>

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

[Linus Walleij]

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>