On 2023-10-05 05:55, Dr. Bernd Feige wrote:
Am Dienstag, dem 26.09.2023 um 17:54 -0700 schrieb Paul Aurich:
Perhaps the laundromat thread should be using msleep_interruptible()?
Using an interruptible sleep appears to prevent the thread from
contributing
to the load average, and has the happy side-effect of removing the
up-to-1s delay
when tearing down the tcon (since a7c01fa93ae, kthread_stop() will
return
early triggered by kthread_stop).
Sorry for chiming in so late - I'm also on gentoo (kernel 6.5.5-
gentoo), but as a client of Windows AD.
Just want to emphasize that using uninterruptible sleep has not just
unhappy but devastating side-effects.
I have 8 processors and 16 cifsd-cfid-laundromat processes, so
/proc/loadavg reports a load average of 16 on a totally idle system.
This means that load-balancing software will never start additional
tasks on this system - "make -l" but also any other load-dependent
system. Just reducing the number of cifsd-cfid-laundromat processes
does not fix this - even a single one makes loadavg report a wrong
result for load balancing.
So, if cifsd-cfid-laundromat must really be uninterruptible, the only
solution would be to change the way loadavg is computed by the kernel
to exclude uninterruptible but sleeping processes. But must it be
uninterruptible?
Thanks and best regards,
Bernd
This is a huge problem here as well, as a client to Samba using SMB1
(for Unix extensions).
For others encountering this problem, I was able to work around it with
the following snippet:
diff --git a/fs/smb/client/cached_dir.c b/fs/smb/client/cached_dir.c
index 2d5e9a9d5b8b..fc2caccb597a 100644
--- a/fs/smb/client/cached_dir.c
+++ b/fs/smb/client/cached_dir.c
@@ -576,7 +576,7 @@ cifs_cfids_laundromat_thread(void *p)
struct list_head entry;
while (!kthread_should_stop()) {
- ssleep(1);
+ msleep_interruptible(1000);
INIT_LIST_HEAD(&entry);
if (kthread_should_stop())
return 0;
