We've been discussing the following issue with some samba team members and I've been requested to formalize this with a bug report. We have performance test suites that we run on samba releases. We've seen a performance regression (when compared to samba 4.12) when performing a large number of getattr operations (specifically, to retrieve the last modified time). The setup is that we create about 400,000 files and then use SMB to get the last modified time on those files at a controlled rate. We have graphs that show the regression, but here are the number of syscalls that we see in 4.12 vs 4.17 (hopefully, this formats correctly): Name samba 4.12 samba 4.17 syscall_asys_pread_count 1152 1152 syscall_asys_pwrite_count 832 832 syscall_chdir_count 4362 281514403 syscall_closedir_count 102 140758607 syscall_fcntl_count 3264 3264 syscall_fdopendir_count 32 140758607 syscall_fntimes_count 0 832 syscall_fstat_count 150095249 985313737 syscall_ftruncate_count 416 416 syscall_get_alloc_size_count 0 281517638 syscall_getwd_count 797 56 syscall_openat_count 0 844552242 syscall_readdir_count 1712 2746633627 syscall_realpath_count 150095079 281517622 syscall_stat_count 1050658924 844541884 syscall_telldir_count 1476 2465116381 (I don't want to break the "one bug per case" rule, but in case it's relevant to this, I'll mention in passing that we see a similar regression when running a performance suite that concentrates on directory listings, but we don't have a comparative list of syscalls for that case yet. I can file a separate case for that once we collect our data.) Thanks, Paul
Hello Paul, thanks for logging the bugreport! I really wonder why there's such an increase for syscalls like chdir, readdir and telldir. As dicussed, this likely requires some largish and dedicated engineering resources.
Backing up Ralph here. We really need to understand *exactly* what your performance test suite is doing in order to work on specifics.