From patchwork Fri Feb 1 20:04:12 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pavel Shilovsky X-Patchwork-Id: 1035145 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-cifs-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="BzLgvT8G"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 43rp3v0Yrzz9s6w for ; Sat, 2 Feb 2019 07:04:59 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730964AbfBAUE6 (ORCPT ); Fri, 1 Feb 2019 15:04:58 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:45021 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730787AbfBAUE6 (ORCPT ); Fri, 1 Feb 2019 15:04:58 -0500 Received: by mail-pl1-f195.google.com with SMTP id p4so464447plq.11 for ; Fri, 01 Feb 2019 12:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references; bh=V+Ma/W/HROjy51lLUDIsOEXiXNxj0ddW5oujNV1TfkM=; b=BzLgvT8GcbJkbeBcxy1m6kJs2YtaQKXeNo84E6kuu3HudwaM0JGkpk9C2k2RLw55g6 yDWojSxSghAvgycz64lBIhqgNc0FClMkT+UYm/4XTC4i7bhqs+Ddcb0QsukHbPzMUVLj KETRUHglGJzjH9/D245pq00aDMJBR8e5hIp8V8prHjMM7E8v5sMd6Jq/hE0+q2cHmCQl tJro4jmp5SpMs1GApJQCSHyGe7gm8io88OJ08oBhU8cHR+UxU6SJs3ubBIhJLnoFrqR3 R15a75zTnZaqA88cIwm1t4N6CE5qJK+dqvFuZlz+mKWAvJr07qCV7KYHzOnVSpjk8hJl mFJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=V+Ma/W/HROjy51lLUDIsOEXiXNxj0ddW5oujNV1TfkM=; b=oyG0cAbYudPYJJMD79n+MY0eBb0YgUdHhooaOXZuXahFICq1WEulfKXZgbw8gyTKln cp52CXI49eBgm6Qsn5gn71Pay4vE/bx//TSuX0OtPJ+6/qVPch68uM7U7Kcx1IcwR4fH R02HnhXqbjtYAqAno6TydciTc4F+um7aJieXS1BVn5jZ28zYwkMILhJxZ80PA2j1e4mY mI2eGQVC0YhPQWTOcZAwsucYaWrFgXEDuXCSFZfmxSSZ8SXSKcM5ICHTO9eWh8LZPv+K qRB82zoJW/1vrxLxsZWN0fgOOHo/Aq2vhWNZfYoIST4DYErAd829iUdUUvCnXbDFKbHU dtlA== X-Gm-Message-State: AJcUukekp7fu65qTnJFi2dmAuU4xMPPjmqO0B7mtaY6QJzDRueso5fM6 Qq8LUkQA7MI2VgYxxDHkcnhZRxU= X-Google-Smtp-Source: ALg8bN4MJC9ePmxJf9OYX3nPJXqAocp7egnMK6SgrOElxYawKPVzcHx9q6nrm5Z3OW0RptiidgG2Iw== X-Received: by 2002:a17:902:3064:: with SMTP id u91mr40226141plb.325.1549051497395; Fri, 01 Feb 2019 12:04:57 -0800 (PST) Received: from ubuntu-vm.corp.microsoft.com ([2001:4898:80e8:0:a18e:4e9f:6b7c:507d]) by smtp.gmail.com with ESMTPSA id x11sm24247451pfe.72.2019.02.01.12.04.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Feb 2019 12:04:55 -0800 (PST) From: Pavel Shilovsky X-Google-Original-From: Pavel Shilovsky To: linux-cifs@vger.kernel.org Subject: [PATCH 23/23] CIFS: Try to acquire credits at once for compound requests Date: Fri, 1 Feb 2019 12:04:12 -0800 Message-Id: <1549051452-5968-25-git-send-email-pshilov@microsoft.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1549051452-5968-1-git-send-email-pshilov@microsoft.com> References: <1549051452-5968-1-git-send-email-pshilov@microsoft.com> Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org Currently we get one credit per compound part of the request individually. This may lead to being stuck on waiting for credits if multiple compounded operations happen in parallel. Try acquire credits for all compound parts at once. Return immediately if not enough credits and too few requests are in flight currently thus narrowing the possibility of infinite waiting for credits. The more advance fix is to return right away if not enough credits for the compound request and do not look at the number of requests in flight. The caller should handle such situations by falling back to sequential execution of SMB commands instead of compounding. Signed-off-by: Pavel Shilovsky --- fs/cifs/transport.c | 39 ++++++++++++++++++++++++++++++++++----- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c index 2187bc3..d4f1224f 100644 --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -886,13 +886,41 @@ compound_send_recv(const unsigned int xid, struct cifs_ses *ses, if (ses->server->tcpStatus == CifsExiting) return -ENOENT; + spin_lock(&ses->server->req_lock); + if (ses->server->credits < num_rqst) { + /* + * Return immediately if not too many requests in flight since + * we will likely be stuck on waiting for credits. + */ + if (ses->server->in_flight < num_rqst - ses->server->credits) { + spin_unlock(&ses->server->req_lock); + return -ENOTSUPP; + } + } else { + /* enough credits to send the whole compounded request */ + ses->server->credits -= num_rqst; + ses->server->in_flight += num_rqst; + first_instance = ses->server->reconnect_instance; + } + spin_unlock(&ses->server->req_lock); + + if (first_instance) { + cifs_dbg(FYI, "Acquired %d credits at once\n", num_rqst); + for (i = 0; i < num_rqst; i++) { + credits[i].value = 1; + credits[i].instance = first_instance; + } + goto setup_rqsts; + } + /* + * There are not enough credits to send the whole compound request but + * there are requests in flight that may bring credits from the server. + * This approach still leaves the possibility to be stuck waiting for + * credits if the server doesn't grant credits to the outstanding + * requests. This should be fixed by returning immediately and letting + * a caller fallback to sequential commands instead of compounding. * Ensure we obtain 1 credit per request in the compound chain. - * It can be optimized further by waiting for all the credits - * at once but this can wait long enough if we don't have enough - * credits due to some heavy operations in progress or the server - * not granting us much, so a fallback to the current approach is - * needed anyway. */ for (i = 0; i < num_rqst; i++) { rc = wait_for_free_request(ses->server, timeout, optype, @@ -932,6 +960,7 @@ compound_send_recv(const unsigned int xid, struct cifs_ses *ses, } } +setup_rqsts: /* * Make sure that we sign in the same order that we send on this socket * and avoid races inside tcp sendmsg code that could cause corruption