[PATCH v2 5/8] hv_balloon: don't check for memhp_auto_online manually
David Hildenbrand
david at redhat.com
Wed Mar 18 03:33:05 AEDT 2020
On 17.03.20 17:29, Vitaly Kuznetsov wrote:
> David Hildenbrand <david at redhat.com> 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 at redhat.com>
>
Thanks!
--
Thanks,
David / dhildenb
More information about the Linuxppc-dev
mailing list