Searched hist:cc8a4d5a (Results 1 – 5 of 5) sorted by relevance
/openbmc/linux/drivers/gpu/drm/msm/ |
H A D | msm_gem_shrinker.c | cc8a4d5a Wed Mar 31 20:27:19 CDT 2021 Rob Clark <robdclark@chromium.org> drm/msm: Avoid mutex in shrinker_count()
When the system is under heavy memory pressure, we can end up with lots of concurrent calls into the shrinker. Keeping a running tab on what we can shrink avoids grabbing a lock in shrinker->count(), and avoids shrinker->scan() getting called when not profitable.
Also, we can keep purged objects in their own list to avoid re-traversing them to help cut down time in the critical section further.
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
|
H A D | msm_gem.h | cc8a4d5a Wed Mar 31 20:27:19 CDT 2021 Rob Clark <robdclark@chromium.org> drm/msm: Avoid mutex in shrinker_count()
When the system is under heavy memory pressure, we can end up with lots of concurrent calls into the shrinker. Keeping a running tab on what we can shrink avoids grabbing a lock in shrinker->count(), and avoids shrinker->scan() getting called when not profitable.
Also, we can keep purged objects in their own list to avoid re-traversing them to help cut down time in the critical section further.
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
|
H A D | msm_drv.h | cc8a4d5a Wed Mar 31 20:27:19 CDT 2021 Rob Clark <robdclark@chromium.org> drm/msm: Avoid mutex in shrinker_count()
When the system is under heavy memory pressure, we can end up with lots of concurrent calls into the shrinker. Keeping a running tab on what we can shrink avoids grabbing a lock in shrinker->count(), and avoids shrinker->scan() getting called when not profitable.
Also, we can keep purged objects in their own list to avoid re-traversing them to help cut down time in the critical section further.
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
|
H A D | msm_gem.c | cc8a4d5a Wed Mar 31 20:27:19 CDT 2021 Rob Clark <robdclark@chromium.org> drm/msm: Avoid mutex in shrinker_count()
When the system is under heavy memory pressure, we can end up with lots of concurrent calls into the shrinker. Keeping a running tab on what we can shrink avoids grabbing a lock in shrinker->count(), and avoids shrinker->scan() getting called when not profitable.
Also, we can keep purged objects in their own list to avoid re-traversing them to help cut down time in the critical section further.
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
|
H A D | msm_drv.c | cc8a4d5a Wed Mar 31 20:27:19 CDT 2021 Rob Clark <robdclark@chromium.org> drm/msm: Avoid mutex in shrinker_count()
When the system is under heavy memory pressure, we can end up with lots of concurrent calls into the shrinker. Keeping a running tab on what we can shrink avoids grabbing a lock in shrinker->count(), and avoids shrinker->scan() getting called when not profitable.
Also, we can keep purged objects in their own list to avoid re-traversing them to help cut down time in the critical section further.
Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
|