From 0fd152dab3db152c8734b5ee0e312cab4257cd04 Mon Sep 17 00:00:00 2001 From: Pierre-Eric Pelloux-Prayer Date: Wed, 9 Jun 2021 13:52:36 +0200 Subject: [PATCH] disk_cache: use UTIL_QUEUE_INIT_SCALE_THREADS MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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: --- src/util/disk_cache.c | 1 + 1 file changed, 1 insertion(+) 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)) -- 2.7.4