You probably want these two as well https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=2da338ff752a2789470d733111a5241f30026675 https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=3b8bb3171571f92eda863e5f78b063604c61f72a as directory leases isn't supported in SMB1, so no waste of system resources by having those kthreads running. On 13 October 2023 20:52:11 GMT-03:00, Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote: >Could you please try two commits[1][2] from for-next? > >[1] https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=e95f3f74465072c2545d8e65a3c3a96e37129cf8 >[2] https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=81ba10959970d15c388bf29866b01b62f387e6a3 > >On 13 October 2023 20:19:37 GMT-03:00, matoro <matoro_mailinglist_kernel@xxxxxxxxx> wrote: >>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;
