Re: [PATCH v2 3/3] percpu: improve allocation success rate for non-GFP_KERNEL callers

From: Tahsin Erdogan
Date: Mon Feb 27 2017 - 12:01:48 EST


On Mon, Feb 27, 2017 at 7:25 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> /*
> * No space left. Create a new chunk. We don't want multiple
> * tasks to create chunks simultaneously. Serialize and create iff
> * there's still no empty chunk after grabbing the mutex.
> */
> if (is_atomic)
> goto fail;
>
> right before pcpu_populate_chunk so is this actually a problem?

Yes, this prevents adding more pcpu chunks and so cause "atomic" allocations
to fail more easily.

>> By the way, I now noticed the might_sleep() in alloc_vmap_area() which makes
>> it unsafe to call vmalloc* in GFP_ATOMIC contexts. It was added recently:
>
> Do we call alloc_vmap_area from true atomic contexts (aka from under
> spinlocks etc)? I thought this was a nogo and GFP_NOWAIT resp.
> GFP_ATOMIC was more about optimistic request resp. access to memory
> reserves rather than true atomicity requirements.

In the call path that I am trying to fix, the caller uses GFP_NOWAIT mask.
The caller is holding a spinlock (request_queue->queue_lock) so we can't afford
to sleep.