Haren Myneni <ha...@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 <ha...@linux.ibm.com> > Suggested-by: Nathan Lynch <nath...@linux.ibm.com>
Reviewed-by: Nathan Lynch <nath...@linux.ibm.com> IMO this can be converted to a more generic helper in the future, should one emerge.
