mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2025-01-19 11:16:16 +07:00
d2a8cfc6f3
It has been postulated that the pm_lock is bad for performance because a CPU currently running rpmh_flush() could block other CPUs from coming out of idle. Similarly CPUs coming out of / going into idle all need to contend with each other for the spinlock just to update the variable tracking who's in PM. Let's optimize this a bit. Specifically: - Use a count rather than a bitmask. This is faster to access and also means we can use the atomic_inc_return() function to really detect who the last one to enter PM was. - Accept that it's OK if we race and are doing the flush (because we think we're last) while another CPU is coming out of idle. As long as we block that CPU if/when it tries to do an active-only transfer we're OK. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200504104917.v6.5.I295cb72bc5334a2af80313cbe97cb5c9dcb1442c@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> |
||
|---|---|---|
| .. | ||
| actions | ||
| amlogic | ||
| aspeed | ||
| atmel | ||
| bcm | ||
| dove | ||
| fsl | ||
| gemini | ||
| imx | ||
| ixp4xx | ||
| kendryte | ||
| lantiq | ||
| mediatek | ||
| qcom | ||
| renesas | ||
| rockchip | ||
| samsung | ||
| sifive | ||
| sunxi | ||
| tegra | ||
| ti | ||
| ux500 | ||
| versatile | ||
| xilinx | ||
| zte | ||
| Kconfig | ||
| Makefile | ||