[Drbd-dev] [PATCH] drbd: Avoid GFP_KERNEL allocation from alloc_send_buffer()

[Tetsuo Handa]

On 2019/04/25 22:51, Philipp Reisner wrote:
>> What happens if nobody volunteers a page when current thread is
>> calling new_or_recycle_send_buffer_page() ? In other words, may I ask
>> the reason why GFP_NOIO is safe here?
> 
> We always have one buffer page allocated. When the previous send_page()
> finishes this buffer page gets recycled (it's page count drops to 1).
> If the system has free memory for DRBD we are happy to use a new page 
> as the next buffer page, speeding up things, as we do not need to wait
> for previous data to be finally sent.
> It is guaranteed that we make progress here. Either because we get
> memory (a) or because the previous buffer becomes reusable (b).

Then, I think that using GFP_NOIO here is NOT safe because alloc_page(GFP_NOIO)
can't return NULL even if the previous buffer's page count dropped to 1 because
current thread will keep looping inside __alloc_pages_nodemask() due to
'The "too small to fail" memory-allocation rule' after current thread once
reached alloc_page(GFP_NOIO).

If you guarantee that page count drops to 1 by waiting for the previous send_page()
to finish, GFP_NOWAIT | __GFP_NOWARN or GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN
should be used instead of GFP_NOIO | __GFP_NOWARN.

Also, GFP_ATOMIC | __GFP_NOWARN would be OK for speeding up things if
at most only a few dozens of pages are allocated here.