From patchwork Tue Jun 20 03:41:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve French X-Patchwork-Id: 1796892 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=2620:137:e000::1:20; helo=out1.vger.email; envelope-from=linux-cifs-owner@vger.kernel.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=ZK7Kr7uP; dkim-atps=neutral Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by legolas.ozlabs.org (Postfix) with ESMTP id 4QlXWX3Xzqz20Wk for ; Tue, 20 Jun 2023 13:42:16 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229489AbjFTDmM (ORCPT ); Mon, 19 Jun 2023 23:42:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbjFTDmL (ORCPT ); Mon, 19 Jun 2023 23:42:11 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A575C6 for ; Mon, 19 Jun 2023 20:42:10 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2b45b6adffbso54007891fa.3 for ; Mon, 19 Jun 2023 20:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687232528; x=1689824528; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hFbkYkkrMNNIj4N+I29G2MMgLDIaZKEdSnmWCRzSWo0=; b=ZK7Kr7uP8pvDkzTYd4j2Z72nyj+0WL5lWS5cqdIG0g4M8KJM0YndoIQh/OaYcmEGrz h+G74qGI5I7upJU4ZSAjUJMhNqj6BLW6gbIUdVjwjgdKQNdG8Ex5ObHayKO/NCzuNI7G fngoioUmrZefGcKVgeLFhciYduDG6DocIM5es/Y+xjYL2nb9yymk4EQDrVIQVXG0lcdJ 2Uf0EWn2EYmqdZ9gik2khPBPRNh7G6mwcHggXBLGdADiPsypeR4Uf4NQSfYEO3Xd1ysc sQ6oan2dEELPakjm3AczlBcA1N6K0grurAFb/FcTT4pD2ff0HAN3j0iK1XiGXVpfwf+S PfwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687232528; x=1689824528; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hFbkYkkrMNNIj4N+I29G2MMgLDIaZKEdSnmWCRzSWo0=; b=iY6ZbYIdz4Yu2LgVZpmU3wb0bP544nKwl70Rl5Z+z7zpaMdxqM9eJPKHDWRZM9FMTY T5+Ilj7kD4tmzeESoDxjWW+zq3Ff6Z5ThZS06F93draX6q94ivMdOrJuQY2CyWTtBvf0 ODQRMyrbJHjW2d/Bl+9NODDaBlknCTIf5RD6C68OrBzyGLgzgeQ54nDCNrSQMekyOPaq xiGw9DKh2ifmi1apk3e7pDN0m/Oml53lcnO51j9pR3RYWiYEAg4h10z/eW0wU7PfRIpu g3Jv6isFkCTiMx+95nL6VaZsaaWUk/QJ+4875UzDUtGeAKIvpnpmP+yHcWifmuS/bQfz 3bRQ== X-Gm-Message-State: AC+VfDwJdLjX72jr3hnEuuLvi3/keNWpqgxlZ+5fybTz4W1pD03WP8CH oML8GVA+EuPt/4PwtJSCwQf4LflTf4LNw8pYJXVDwmuEmOI= X-Google-Smtp-Source: ACHHUZ47LaP9OEcbLsRrAPhhj0j31yJe8lm0XjScN/L6sbQvclG021qSrrAdRgoYwFb5baC18TX7xtOY4QxxSU6rnAk= X-Received: by 2002:a2e:2c0f:0:b0:2b4:765b:f6f0 with SMTP id s15-20020a2e2c0f000000b002b4765bf6f0mr3097600ljs.28.1687232527735; Mon, 19 Jun 2023 20:42:07 -0700 (PDT) MIME-Version: 1.0 From: Steve French Date: Mon, 19 Jun 2023 22:41:56 -0500 Message-ID: Subject: [SMB CLIENT][PATCH] do not reserve too many oplock credits To: CIFS Cc: Shyam Prasad N X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org There were cases reported where servers will sometimes return more credits than requested on oplock break responses, which can lead to most of the credits being allocated for oplock breaks (instead of for normal operations like read and write) if number of SMB3 requests in flight always stays above 0 (the oplock and echo credits are rebalanced when in flight requests goes down to zero). If oplock credits gets unexpectedly large (e.g. ten is more than it would ever be expected to be) and in flight requests are greater than zero, then rebalance the oplock credits and regular credits (go back to reserving just one oplock credit. See attached From c50cae15903fc704c3df1170183c8505cd2eb0b9 Mon Sep 17 00:00:00 2001 From: Steve French Date: Mon, 19 Jun 2023 22:32:38 -0500 Subject: [PATCH] smb3: do not reserve too many oplock credits There were cases reported where servers will sometimes return more credits than requested on oplock break responses, which can lead to most of the credits being allocated for oplock breaks (instead of for normal operations like read and write) if number of SMB3 requests in flight always stays above 0 (the oplock and echo credits are rebalanced when in flight requests goes down to zero). If oplock credits gets unexpectedly large (e.g. ten is more than it would ever be expected to be) and in flight requests are greater than zero, then rebalance the oplock credits and regular credits (go back to reserving just one oplock crdit). Signed-off-by: Steve French --- fs/smb/client/smb2ops.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index a8bb9d00d33a..02780f175571 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -109,7 +109,11 @@ smb2_add_credits(struct TCP_Server_Info *server, server->credits--; server->oplock_credits++; } - } + } else if ((server->in_flight > 0) && (server->oplock_credits > 10) && + ((optype & CIFS_OP_MASK) == CIFS_OBREAK_OP)) + /* if now have too many oplock credits, rebalance so don't starve normal ops */ + change_conf(server); + scredits = *val; in_flight = server->in_flight; spin_unlock(&server->req_lock); -- 2.34.1