Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp855050ybb; Fri, 10 Apr 2020 11:26:19 -0700 (PDT) X-Google-Smtp-Source: APiQypI32TS9FK5jXMtXMGl4N9LlZRb0yrzbimxPvdij5r70Qx2g6c2X5IMU9/MUpG50scRgghGr X-Received: by 2002:a37:678f:: with SMTP id b137mr5247588qkc.500.1586543179503; Fri, 10 Apr 2020 11:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586543179; cv=none; d=google.com; s=arc-20160816; b=Nvq8PebHP3HCNb6xu94glJ0v9ncgPWtDJ4oeaqYeJ7wp+8fA1oEX6E0tNcsYq5kkeW GvKGySNqGFb4ditvBf7XxOucW5C+pIgTwLDTnTsnChxO4GyqUHUp4Or9oTf4NC/WMc2B KQBiSZc9p5XS9ZmJVTRMcVGEaona1cNmn9dkqgUQg/8/MgTHQD1WftOfzvdiHXpFeWZN mJGdp3we1fqExFZz3PumSkvok6qmJlxfNkA/M1lqxqY5qUMQ/7aiirHC4B20Nie1FdSW ejCgJD/uWZhSUZpU0Rl4TSqhwUe51uqsgFApaSmXUhw1YZMaRmIk5ZA/18I6Lmc9dD/x 1VCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=/8e9T1aA34gtipux6MRR5JeX22u4u6r+1ck6KMnDmCE=; b=GgNdpfq4m35+gl4w7yQhZdmnRT/n0jxYyGv0DDdVz0CNepvHKwI3mcVb8xv935JcPx nvNazmndcKoIwVUuuyYgj1Z87Zjqjn7pUgJYYUPm2sufr+c7H+GGD801supL6O/rfE2F R7MjOSQ85o7LFE2GBzRATJEF7i7Inoz1Mhb7YaGaqdFNUnxcg4z/1Iw3mYZFsJ/ZFL6A VSDBZuuRBvmCyYwMio04YHVoLsIEvwOJ1VHnUhGLEMe1jRSF2eo4QEHkw9iklYZoTr+V NTozaTUTDY9jchCRl39sXtoAA2bC5/ltJQZ4DNVhpPQ9n7Ua2Nj02SLDxjhtr1D0vRJB X6Ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kuBRYMu3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b27si1605831qta.382.2020.04.10.11.26.03; Fri, 10 Apr 2020 11:26:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kuBRYMu3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726648AbgDJSZO (ORCPT + 99 others); Fri, 10 Apr 2020 14:25:14 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:38281 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbgDJSZO (ORCPT ); Fri, 10 Apr 2020 14:25:14 -0400 Received: by mail-lj1-f196.google.com with SMTP id v16so2796560ljg.5; Fri, 10 Apr 2020 11:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/8e9T1aA34gtipux6MRR5JeX22u4u6r+1ck6KMnDmCE=; b=kuBRYMu3ElDdUOqhfqRSlgM/BaOIhxXtbQtiKml+rK+iyzUZA43MpO84UTIkfHrVN9 Dvn1KyBG5uOLPETwcDcKZnG+2R35EJiA+e4Zb/nzsqh2CmhAX76tnPzDqSMeu+A6dZ4V gSL/kwpLt846Hk2vlz1vx+4AEg2KUVvde7y6jMWzwR3/kWVuECqx4qB4pbD0nQ5BLy6J aTkFFVl7e6OlRAqzXKZjBP6gLuqP+gszOlydcDkyctpCR67a6J7vO2Y7ekvjS1s7QK3e zNUmogZmUf665osEUT1X6SU0WhGtPtcXMRK06NMRCAXGf639kIUGjiThmt9k4RV3LFj3 UdeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/8e9T1aA34gtipux6MRR5JeX22u4u6r+1ck6KMnDmCE=; b=YIAUh781wGb8DL6WJconsWsHNCm5bN7vKkRv3Q+O3KtJQXEE/4ceg5gF2lL02X/ebm wJKdHSkSYknoxe9OjV2IJvDoQPgxl5C2Pf7+TNooqMUmAF7ORx+RrrymMToMrrjapuyi USgg+tR+9Z8SEiJEysplsQ23rYung0yE6eeI8AJgz9GuiTjNlMQc6DuAu1kd3VrJWwPh Nyup8Rsbzk8n2sfQS9S1dg++xZiK62HCQSTW3CmqfgegVpX40gxPi9VsQ3NIQoNVi+aw 7py09/4BHDci7iBgdcNbjGmDFQjE1dXvo6DBV+kJ6D4GjpAfof/b4otoky4lkETZWufq Hr8g== X-Gm-Message-State: AGi0PuYMu8KwiRnHvFipYXlNYtYdyM0y7bzNT5SsV4qeJjiUIzDDU8zw DN/Tlf/TtzGlQcsd4ih1o9x4Ir2kvo+C7L18rw== X-Received: by 2002:a2e:2286:: with SMTP id i128mr3641945lji.109.1586543112254; Fri, 10 Apr 2020 11:25:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Shilovsky Date: Fri, 10 Apr 2020 11:25:01 -0700 Message-ID: Subject: Re: [PATCH] cifs: improve read performance for page size 64KB & cache=strict & vers=2.1+ To: Jones Syue Cc: linux-cifs , Samba Technical , Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org =D0=BF=D1=82, 10 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 09:50, Jones Syue = via samba-technical : > > Hello list, > > please help review whether the attached patch is correct, thank you. > > Found a read performance issue when linux kernel page size is 64KB. > If linux kernel page size is 64KB and mount options cache=3Dstrict & > vers=3D2.1+, > it does not support cifs_readpages(). Instead, it is using cifs_readpage(= ) > and > cifs_read() with maximum read IO size 16KB, which is much slower than rea= d > IO > size 1MB when negotiated SMB 2.1+. Since modern SMB server supported SMB > 2.1+ > and Max Read Size can reach more than 64KB (for example 1MB ~ 8MB), this > patch > do one more check on max_read to determine whether server support > readpages() > and improve read performance for page size 64KB & cache=3Dstrict & vers= =3D2.1+. > > The client is a linux box with linux kernel 4.2.8, > page size 64KB (CONFIG_ARM64_64K_PAGES=3Dy), > cpu arm 1.7GHz, and use mount.cifs as smb client. > The server is another linux box with linux kernel 4.2.8, > share a file '10G.img' with size 10GB, > and use samba-4.7.12 as smb server. > > The client mount a share from the server with different > cache options: cache=3Dstrict and cache=3Dnone, > mount -tcifs ///Public /cache_strict > -overs=3D3.0,cache=3Dstrict,username=3D,password=3D > mount -tcifs ///Public /cache_none > -overs=3D3.0,cache=3Dnone,username=3D,password=3D > > The client download a 10GbE file from the server accross 1GbE network, > dd if=3D/cache_strict/10G.img of=3D/dev/null bs=3D1M count=3D10240 > dd if=3D/cache_none/10G.img of=3D/dev/null bs=3D1M count=3D10240 > > Found that cache=3Dstrict (without patch) is slower read throughput and > smaller > read IO size than cache=3Dnone. > cache=3Dstrict (without patch): read throughput 40MB/s, read IO size is 1= 6KB > cache=3Dstrict (with patch): read throughput 113MB/s, read IO size is 1MB > cache=3Dnone: read throughput 109MB/s, read IO size is 1MB > > Looks like if page size is 64KB, > cifs_set_ops() would use cifs_addr_ops_smallbuf instead of cifs_addr_ops, > > /* check if server can support readpages */ > if (cifs_sb_master_tcon(cifs_sb)->ses->server->maxBuf < > PAGE_SIZE + MAX_CIFS_HDR_SIZE) > inode->i_data.a_ops =3D &cifs_addr_ops_smallbuf; > else > inode->i_data.a_ops =3D &cifs_addr_ops; > > maxBuf is came from 2 places, SMB2_negotiate() and CIFSSMBNegotiate(), > (SMB2_MAX_BUFFER_SIZE is 64KB) > SMB2_negotiate(): > /* set it to the maximum buffer size value we can send with 1 credit */ > server->maxBuf =3D min_t(unsigned int, le32_to_cpu(rsp->MaxTransactSize), > SMB2_MAX_BUFFER_SIZE); > CIFSSMBNegotiate(): > server->maxBuf =3D le32_to_cpu(pSMBr->MaxBufferSize); > > Page size 64KB and cache=3Dstrict lead to read_pages() use cifs_readpage(= ) > instead > of cifs_readpages(), and then cifs_read() using maximum read IO size 16KB= , > which is much slower than maximum read IO size 1MB. > (CIFSMaxBufSize is 16KB by default) > > /* FIXME: set up handlers for larger reads and/or convert to async */ > rsize =3D min_t(unsigned int, cifs_sb->rsize, CIFSMaxBufSize); > Hi Jones, Thanks for the patch! It will work although it is probably a little bit cleaner to initialize server->max_read to server->maxBuf for SMB1 and use the server->max_read in the readpages condition check instead. @Others, thoughts? -- Best regards, Pavel Shilovsky