mirror of
https://github.com/torvalds/linux.git
synced 2024-11-28 15:11:31 +00:00
43ac9f5cd4
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@linux.ibm.com> Suggested-by: Nathan Lynch <nathanl@linux.ibm.com> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240116055910.421605-1-haren@linux.ibm.com |
||
---|---|---|
.. | ||
4xx | ||
8xx | ||
40x | ||
44x | ||
52xx | ||
82xx | ||
83xx | ||
85xx | ||
86xx | ||
512x | ||
amigaone | ||
book3s | ||
cell | ||
chrp | ||
embedded6xx | ||
maple | ||
microwatt | ||
pasemi | ||
powermac | ||
powernv | ||
ps3 | ||
pseries | ||
fsl_uli1575.c | ||
Kconfig | ||
Kconfig.cputype | ||
Makefile |