From bd04725444b7ab15ea81647c519a580ca50a94de Mon Sep 17 00:00:00 2001 From: Peter Amstutz Date: Mon, 1 Apr 2024 20:32:49 -0400 Subject: [PATCH] 21639: Note about 0 prefetch threads Arvados-DCO-1.1-Signed-off-by: Peter Amstutz --- services/fuse/arvados_fuse/command.py | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/services/fuse/arvados_fuse/command.py b/services/fuse/arvados_fuse/command.py index 29ace2e52e..4c8ae899e1 100644 --- a/services/fuse/arvados_fuse/command.py +++ b/services/fuse/arvados_fuse/command.py @@ -482,12 +482,11 @@ class Mount(object): disk_cache=self.args.disk_cache, disk_cache_dir=self.args.disk_cache_dir) - # If there's too many prefetch threads and you - # max out the CPU, delivering data to the FUSE - # layer actually ends up being slower. - # Experimentally, capping 7 threads seems to - # be a sweet spot. - #prefetch_threads = min(max((block_cache.cache_max // (64 * 1024 * 1024)) - 1, 1), 7) + # Profiling indicates that prefetching has more of a + # negative impact on the read() fast path (by requiring it + # to do more work and take additional locks) than benefit. + # Also, the kernel does some readahead itself, which has a + # similar effect. prefetch_threads = 0 self.api = arvados.safeapi.ThreadSafeApiCache( -- 2.30.2