Re: [PATCH v2 5/8] hv_balloon: don't check for memhp_auto_online manually

From: David Hildenbrand
Date: Tue Mar 17 2020 - 12:33:16 EST


On 17.03.20 17:29, Vitaly Kuznetsov wrote:
> David Hildenbrand <david@xxxxxxxxxx> writes:
>
>> We get the MEM_ONLINE notifier call if memory is added right from the
>> kernel via add_memory() or later from user space.
>>
>> Let's get rid of the "ha_waiting" flag - the wait event has an inbuilt
>> mechanism (->done) for that. Initialize the wait event only once and
>> reinitialize before adding memory. Unconditionally call complete() and
>> wait_for_completion_timeout().
>>
>> If there are no waiters, complete() will only increment ->done - which
>> will be reset by reinit_completion(). If complete() has already been
>> called, wait_for_completion_timeout() will not wait.
>>
>> There is still the chance for a small race between concurrent
>> reinit_completion() and complete(). If complete() wins, we would not
>> wait - which is tolerable (and the race exists in current code as
>> well).
>
> How can we see concurent reinit_completion() and complete()? Obvioulsy,
> we are not onlining new memory in kernel and hv_mem_hot_add() calls are
> serialized, we're waiting up to 5*HZ for the added block to come online
> before proceeding to the next one. Or do you mean we actually hit this
> 5*HZ timeout, proceeded to the next block and immediately after
> reinit_completion() we saw complete() for the previously added block?

Yes exactly - or if an admin manually offlines+re-onlines a random
memory block.

> This is tolerable indeed, we're making forward progress (and this all is
> 'best effort' anyway).

Exactly my thoughts.

[...]

>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>

Thanks!

--
Thanks,

David / dhildenb