Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp1299215rdg; Fri, 13 Oct 2023 17:59:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH9EVmOBjrFWVwO3u2QhXzB69atyVfRx2nR2lj9Bj6SxgCvrD4my04htlXRD/zD7Myt8Gnv X-Received: by 2002:a05:6a21:1a6:b0:153:4ea6:d12e with SMTP id le38-20020a056a2101a600b001534ea6d12emr2433860pzb.17.1697245196392; Fri, 13 Oct 2023 17:59:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697245196; cv=none; d=google.com; s=arc-20160816; b=jcw/l2sRbgMda9XqIRn0RcZXT2GGZ7ogIEni/+3oaFhg//YmH1YCIHDciyv4KXNpSy E7M85PikdrCzRamNAUcd9j456fofoJV4iAHjoSt3XH6T64MYkXNvUpKAPuU5HqlyqfCq 2BcZKEwIRWliWeIBGHAA4tkkKnEOHZ4zV2Aj0gBHaZ7fisUWYJLn9M0I+4c1pLLH9SjH SfjIgliXtd3yWwhmBbHzGyigd0QFbomRZ8OacaAStqsUYExJtue+IxlSKcrDajSuBKxG Qb8DWjEK3uN+xaoikHSKz0obh2DACVOqdGOXJs6tL2A0dku+mxBzhSuS+GeUc0q1LYXZ rTkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:references :in-reply-to:subject:cc:to:from:date:mime-version:dkim-signature; bh=HBXsmAGmocJo6yoWBhkrgxNZCb9WtBCbFZetm3/XVE8=; fh=eVDlwVmebcidyKq/b+6MSK9H4ENR1H/uZLPZKLCFK6M=; b=Cm7M/1CjxR/Uy52u0ga4qHyq6nLNacjD21LAYMC4LvzcDsGyG4y1Xt0Liy+gBgBtrd OPjPGgFq6dKkeYs9xZBXCQCut/qSgLl892xn5TlKGVOI/fMMFd1aHy1R9AFrJzyY9Rgi urlgq2lh0k47aFQKO/H4oAVIFieO7Ltggfgx16LGUaunwzVDU/07/fAE4coW09NNWPuE k6w8ihQd4L3Lyc+uGNY2R8zytpuF+wH6XHlirlZU8/0wVA2TrCyCHZECZ3lAVjDU79gm hzipU/b++u0hnkM621meexCZ37z2hMJEI8UETuIQHG+L9+eB74e7XEo/3EEKesfkKCm7 it9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@matoro.tk header.s=20230917 header.b=YbEaADeE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=matoro.tk Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id l62-20020a638841000000b005ac3e5ccc66si2226687pgd.43.2023.10.13.17.59.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 17:59:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@matoro.tk header.s=20230917 header.b=YbEaADeE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=matoro.tk Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 6EC7C8084745; Fri, 13 Oct 2023 17:59:53 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232540AbjJNA7k (ORCPT + 99 others); Fri, 13 Oct 2023 20:59:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229649AbjJNA7j (ORCPT ); Fri, 13 Oct 2023 20:59:39 -0400 Received: from matoro.tk (unknown [IPv6:2600:1700:4b10:9d80::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A5355BE; Fri, 13 Oct 2023 17:59:34 -0700 (PDT) DKIM-Signature: a=rsa-sha256; bh=HBXsmAGmocJo6yoWBhkrgxNZCb9WtBCbFZetm3/XVE8=; c=relaxed/relaxed; d=matoro.tk; h=Subject:Subject:Sender:To:To:Cc:Cc:From:From:Date:Date:MIME-Version:MIME-Version:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Reply-To:In-Reply-To:In-Reply-To:Message-Id:Message-Id:References:References:Autocrypt:Openpgp; i=@matoro.tk; s=20230917; t=1697245166; v=1; x=1697677166; b=YbEaADeEU+Zf33KJ3Lum1ryo7UJhiVENwcitc417ymfUrcTDld2xvLxEQ2nRbQhVGNLSTRmg VGP/4ZxYHid4nX6Lt57LsZ4TZSS/HhWo4g9WC4BfWpNGFm58AoEbfoKhqkEHPevLAGC84OYXVH6 II2wEh3/g5dxY/sMYwwaZOrJE1sPmHWmKdiACNPSoKppU7ewTsYaf1kRLmkgx8QbAV0UkTz5Pka jbpgiT3c5kV26/sF1jXLHC3zguK0nOarCH7l8YuPj4p49BksXbkmiqvbuRwm2+fMX0TvwimPAZB ZMWczcFsAgWIqfOWl96YOJGh2gCu7iDJtVzTIze68O4rerUb8Di9bGGaqtKZPWas0F3IkAj58hG 0o+zFV1+xBcmMks7Z+azSyKVfxQZxShg5LcS1VXg6KyeP88OngzHCr4WHttyv8GrtbAf1ehAz+/ 4adbYFVH7DV6pHJqHCVJUEGHifRDoaKyjTHA4Z7IBs5vM8hH2n2Tp09XxmE1YEJjYYpnF6IPLrh q6DHymHy/K/TVMReDF4uWf4RcXKjtPNNIYDmTb9B/ZJIQ5Bx5RSGQfjGCLOhv63HWohjDs+UuJg 3arSMb6N0x+sjQrhZhAiLqFUBAbMXoOEykMZWiEy/r+P7GGOv9m5WrlG+oBmn+49PAJg3+xXudI ttE1RPOv2yk= Received: by matoro.tk (envelope-sender ) with ESMTPS id c713fbfd; Fri, 13 Oct 2023 20:59:26 -0400 MIME-Version: 1.0 Date: Fri, 13 Oct 2023 20:59:26 -0400 From: matoro To: Steve French Cc: Paulo Alcantara , "Dr. Bernd Feige" , Tom Talpey , Paul Aurich , CIFS , Bagas Sanjaya , Linux Regressions , ronnie sahlberg , Shyam Prasad N , Brian Pardy , Bharath S M , LKML Subject: Re: Possible bug report: kernel 6.5.0/6.5.1 high load when CIFS share is mounted (cifsd-cfid-laundromat in"D" state) In-Reply-To: References: <85d538fec5a086acf62d5a803056586a6c00e4bd.camel@uniklinik-freiburg.de> <83d00d50bc628a85db71adb440d8afb5@matoro.tk> Message-ID: X-Sender: matoro_mailinglist_kernel@matoro.tk Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 13 Oct 2023 17:59:53 -0700 (PDT) On 2023-10-13 20:13, Steve French wrote: > Let me know if those fixes help as two of them have not been sent to > Linus > yet, but I could send tomorrow > > On Fri, Oct 13, 2023, 19:01 Paulo Alcantara wrote: > >> 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 >> >> 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@matoro.tk> 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; >> Do you have backports of these to 6.5? I tried to do it manually but there's already so many changes between 6.5 and these commits.