From: Pierre-Eric Pelloux-Prayer Date: Wed, 9 Jun 2021 11:52:36 +0000 (+0200) Subject: disk_cache: use UTIL_QUEUE_INIT_SCALE_THREADS X-Git-Tag: upstream/21.2.3~1737 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=0fd152dab3db152c8734b5ee0e312cab4257cd04;p=platform%2Fupstream%2Fmesa.git disk_cache: use UTIL_QUEUE_INIT_SCALE_THREADS Instead of spawning 4 threads when the cache is created, spawn 1 and let u_queue grow the number of threads if needed. I wrote this patch because when running piglit's quick_shader profile I had lots of samples in disk cache threads - mostly in native_queued_spin_lock_slowpath kernel function. Since these tests shouldn't really stress the cache, I assumed it was caused only by thread creations. After writing the patch and redoing the measurement, I got an improvement but I still more hits in the same function for shader_runner:$disk0 thread so something was wrong. After digging more, I found out that my shader cache index was corrupted: the on-disk size was 29MB but the index reported it was way more than 1GB. So each disk cache thread was spending a lot of time trying to evict files. Given that my cache had a really low count of files, the LRU method based on randomly generating subfolder names failed, so evicting was very slow. Now that my cache index is fixed, the disk cache threads are mostly idle but I still think it makes sense to grow the number of threads instead of spawning 4 at the program start. Reviewed-by: Marek Olšák Part-of: --- diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c index 800c204..f519c12 100644 --- a/src/util/disk_cache.c +++ b/src/util/disk_cache.c @@ -172,6 +172,7 @@ disk_cache_create(const char *gpu_name, const char *driver_id, * doesn't stall. */ if (!util_queue_init(&cache->cache_queue, "disk$", 32, 4, + UTIL_QUEUE_INIT_SCALE_THREADS | UTIL_QUEUE_INIT_RESIZE_IF_FULL | UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY | UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY, NULL))