[PATCH v6] powerpc/pseries/vas: Use usleep_range() to support HCALL delay

[Nathan Lynch]

Haren Myneni <haren at linux.ibm.com> writes:
> VAS allocate, modify and deallocate HCALLs returns
> H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
> delay and expects OS to reissue HCALL after that delay. But using
> msleep() will often sleep at least 20 msecs even though the
> hypervisor suggests OS reissue these HCALLs after 1 or 10msecs.
>
> The open and close VAS window functions hold mutex and then issue
> these HCALLs. So these operations can take longer than the
> necessary when multiple threads issue open or close window APIs
> simultaneously, especially might affect the performance in the
> case of repeat open/close APIs for each compression request.
>
> Multiple tasks can open / close VAS windows at the same time
> which depends on the available VAS credits. For example, 240
> cores system provides 4800 VAS credits. It means 4800 tasks can
> execute open VAS windows HCALLs with the mutex. Since each
> msleep() will often sleep more than 20 msecs, some tasks are
> waiting more than 120 secs to acquire mutex. It can cause hung
> traces for these tasks in dmesg due to mutex contention around
> open/close HCALLs.
>
> Instead of msleep(), use usleep_range() to ensure sleep with
> the expected value before issuing HCALL again. So since each
> task sleep 10 msecs maximum, this patch allow more tasks can
> issue open/close VAS calls without any hung traces in the
> dmesg.
>
> Signed-off-by: Haren Myneni <haren at linux.ibm.com>
> Suggested-by: Nathan Lynch <nathanl at linux.ibm.com>

Reviewed-by: Nathan Lynch <nathanl at linux.ibm.com>

IMO this can be converted to a more generic helper in the future, should
one emerge.