From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D2D7C77B72 for ; Fri, 14 Apr 2023 14:42:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36282280004; Fri, 14 Apr 2023 10:42:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31265280002; Fri, 14 Apr 2023 10:42:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DA7E280004; Fri, 14 Apr 2023 10:42:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0EB83280002 for ; Fri, 14 Apr 2023 10:42:35 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D02EE8036F for ; Fri, 14 Apr 2023 14:42:34 +0000 (UTC) X-FDA: 80680262628.30.9DC6EEA Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf12.hostedemail.com (Postfix) with ESMTP id 6443D4001C for ; Fri, 14 Apr 2023 14:42:31 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=dneg.com header.s=google header.b=gwacbKk8; spf=pass (imf12.hostedemail.com: domain of daire@dneg.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=daire@dneg.com; dmarc=pass (policy=none) header.from=dneg.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681483351; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MyWqJg+TEEMkoUyXIV4qRUXghOyIcc1b77Z/puaO8vo=; b=jbONEJkWobgxrx3o5o8vOCPgwbAnyLmp5mF89tQEyjB8XMe7e21fbzW8mz5M2YOoovW7Xg EF34w5CA0efVdvDcZ55HwTJVwznXjZ0WuwO/+hkNz7qKJQfvBO6q1MOHa1So5085x57alM MrHuTuKA+AtWyJIlP7T6nZm7TX9qUx4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=dneg.com header.s=google header.b=gwacbKk8; spf=pass (imf12.hostedemail.com: domain of daire@dneg.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=daire@dneg.com; dmarc=pass (policy=none) header.from=dneg.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681483351; a=rsa-sha256; cv=none; b=1JCMgRnXOEWnu2gpBp5QM17AXe1zIzMBbcpHZEDC+WT2EELLkxjPVOaHAzmffvyEE+BQX5 SWgijub+ibrXXc5xk/qs/h4zmK1YR6MZEuXWwZteHISPJZGlEXHRDDl9iQqJNXPEUyxNOz WJxesvJ3L/sNNUwyySfzY6nXvBmBuHg= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-54fbb713301so106207207b3.11 for ; Fri, 14 Apr 2023 07:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dneg.com; s=google; t=1681483350; x=1684075350; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MyWqJg+TEEMkoUyXIV4qRUXghOyIcc1b77Z/puaO8vo=; b=gwacbKk8ZhAw/+4XWDKbLBigHaYvNUIUpTATkPqb5TsgWk47p0IlMhF4habn6ly3q+ EdOhisafu607FxcK5j2P0BL2S3WpgHAnunYhQ9TrdVySAU3dfKWPIdodlP5wIoBps+63 M5XRXeJyDChxoxs0c08zhUhL/pvQ1jSyM/zKVZuXaz0M0d+udQofR3M9RNbHfFfXM/38 QcgOmDq0hgYAomtXXd+kxVXsJ98oSqM8IJs7kZmovc1mw6nh6GF6Lw9H5eg1uxtSQCVq N1Qio8FeCOrT0UrnDo3JrjCNf/pgm9l7tSjCgTVG5sysEzOTNi4SJUGx4a9fL/bZ6aln Sp9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681483350; x=1684075350; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MyWqJg+TEEMkoUyXIV4qRUXghOyIcc1b77Z/puaO8vo=; b=SL3cCw5FZ6yQcolSvCYf67oxXn/Axor176aN6AeD6voUZF3W6kGc03tLkzbYGY0CzC QN6UCOOEJGrmPpdGaqkntULXNH2DVcdW0nS2yhLqaLOZHrBwlyEH8LcFSSylKZyc36D1 2PxFfeeEa93fVgq7w2R2yPRIqH1LiOpEPsAV4YyReMw4YXSdpt5pNyqCK/O7skSj3yY/ KMFCkmd4WXlKEbg8uqHJ+zvPro1yzY2udkXTA8j4WUBGR1GvcsESN3njVc1EuTlMJR4t SMqdFxTDfEe6V9MSjCb3/rl3v0Jo3c1HUUAt2q7mbl6QQ9N5ssMGOUyOIiGQqvmnZsO/ 5XgQ== X-Gm-Message-State: AAQBX9dUXRFns28scnBfxW+Nsq+YcS2mdjL1Tfg/vfbluKjdXDwB+mi4 HZqYA6bvf/1e/2BglebhQTZlpDteLERTdazACvOTCg== X-Google-Smtp-Source: AKy350ZSIgWGAXJ/jDcFVW6ZtIlOPzVRFSQW/9QwuupeF38JoI4hw3A4zo92XzTsE4M00u8OgP/Ymg6nq18qvR4uLY8= X-Received: by 2002:a81:ae12:0:b0:545:8202:bbcf with SMTP id m18-20020a81ae12000000b005458202bbcfmr3804319ywh.9.1681483350245; Fri, 14 Apr 2023 07:42:30 -0700 (PDT) MIME-Version: 1.0 References: <3A132FA8-A764-416E-9753-08E368D6877A@oracle.com> <812034.1680181285@warthog.procyon.org.uk> <6F2985FF-2474-4F36-BD94-5F8E97E46AC2@oracle.com> <20230329141354.516864-1-dhowells@redhat.com> <20230329141354.516864-41-dhowells@redhat.com> <812755.1680182190@warthog.procyon.org.uk> <822317.1680186419@warthog.procyon.org.uk> In-Reply-To: From: Daire Byrne Date: Fri, 14 Apr 2023 15:41:53 +0100 Message-ID: Subject: Re: [RFC PATCH v2 40/48] sunrpc: Use sendmsg(MSG_SPLICE_PAGES) rather then sendpage To: Chuck Lever III Cc: David Howells , Matthew Wilcox , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Al Viro , Christoph Hellwig , Jens Axboe , Jeff Layton , Christian Brauner , Linus Torvalds , "open list:NETWORKING [GENERAL]" , linux-fsdevel , Linux Kernel Mailing List , Linux Memory Management List , Trond Myklebust , Anna Schumaker , Linux NFS Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: ib6ynq7ampn7qj93qhzj3nk9ijqshxyx X-Rspamd-Queue-Id: 6443D4001C X-HE-Tag: 1681483351-644251 X-HE-Meta: U2FsdGVkX19IRkfDI4zlnz8zuSugS6Y3hRMmPdwiDbf+Xd365dlnPOJAFDPh2BsIPGbZLbY3kTJt/AKhsvPWjZTihbM18addzHxV9k+md88OxssW41kkWqtnTcFeUJIBz1AqNAzMhyEJknyQNtOYdaXVYcsoPzFc28FkaJ6cfF7PPnJBV8to43rAUfnuxP/PfjnzOgoEm8ahwg5N42tX+KnZW9zSbSPbop1pxLQ24bPhJM2OurezFYgn0r70HWuwInIcat/5SGIM3Ymsqp/Yeu3BbSRka1p/5Fj2L0CWrZjnYNOVOXZuKHoFAU9BVVUvGRfX4KR0YnzKmEArlQcNfIqcUQHvcHK+I7dhEcXbY1kO/XSz5YMlDUL24dr3zy2WuPtmu87PkW53uZCzzQnvdqZQs9r+FvqfmMXX2j0x1y6i3kwJMvmW7Sh3DAUp/gPzZVlAt+tPAYIAwo/h8cEUXXx4GXvjmtADrYhPQzAZXu9bMxgJjCq3ahq336otZcsnd6LhDB3o5jYMd/bexSsksN6rbH0ImxFlseWCvKkK+yzIrxo3lvceRlMVckcoowx34nE9j0t0TikkJP2XmQfPQyJkCly8SNcV32wE4OYcFGXwfPRQu7FvqI9d4oc2Ziavwm/l/IpP0w+A7nB858FKFKicixg8AYaoY4G5peWiorTDe0r305LTSN/2A8l0YZJTdbRWE+s2Cuv+FQ0F7uG+IJ6EPbt/La+S340cq591+B228ooHKKRGcf3jTd4xF4e6ARpJtXkDzMFS65ynFrobl98PLV+UWZLjHyZbPEC+JB87M67IiDROTJ/nydMs/UAROYUBHZvC7AOkhePqhV0sdanP6HjQNAtMkDIc/tiZ59mLUny9X/38ekdrjWqjntdqngR2EMvL3yEliwVmj1b3cyOdh9n8zmpfx7d+J89uBZJCnizPKcMAt04LreW4tNbdIquyM/EIUbz6k2YNdYv 7fM14WGv vFkNLjJ9rrGOzhOH2ne10mZbTb+ICmBHy02fUpJAHe2WBTcD4uN9jf0Cblzq6qm+tnMckCtTuP4nXq3wM6Gi/xC+sPF307VqJHMmuiKxAdqV5uZsdDaGzsJikjd8Y/BdUG6seaskrNL7D9N5TjtD/2TnLQqCoc4m44sMyBJJrrzexAZC/GSmFMLanFiiRbN1xPVgFhbVsHO6L4ig6P3nsItnmf/atFTmzQbpacT6CA+c4eBD4xwTi5bITbX9DPoDn+upaEU49W6T9OIl2M7V6MJESqiUTyXR2Vv3PS199lGttMl+RDLbilElG8Ix4mRg05CeDVC3i+/Q6jYtvoawDQgbWsRK5msFa/mRld2wVIDdY4Sz8m83pSSOECURdyJ5FrQ4fEcO1O87/w2DdO4iRRxYwaSoFJFdSgYTy6qscn1lF8wRXKXgMsHEeVk6L/0EPAKXDJzsfY4ylFySCU9xleJ67/Cs5RLtoo9eaZYjNf0PXTmP+eFai6vFbIkUO3ApwiWl63gulfrV8zZtl7vU3ySoaFImBZD+OvXFkaxC74YopUdq5V4I+z6ce6GHs8On7cCslVCOROaJvkcvlssdEwOhDg3tLD4jhXXv+fiE73m1WgWLQ5HaUN51olCgJ537BovDs5mlyAx9+wtQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: I gave this a spin because I had noticed a previous regression around the 5.7 time frame in sendpage/sendmsg code changes: https://bugzilla.kernel.org/show_bug.cgi?id=209439 In that case there was a noticeable regression in performance for high performance servers (100gbit). I see no such performance problems with David's iov-sendpage branch and it all looks good to me with simple benchmarks (100gbit server, 100 x 1gbit clients reading data). Tested-by: Daire Byrne Cheers, Daire On Thu, 30 Mar 2023 at 17:37, Chuck Lever III wrote: > > > > > On Mar 30, 2023, at 10:26 AM, David Howells wrote: > > > > Chuck Lever III wrote: > > > >> Don't. Just change svc_tcp_send_kvec() to use sock_sendmsg, and > >> leave the marker alone for now, please. > > > > If you insist. See attached. > > Very good, thank you for accommodating my regression paranoia. > > Acked-by: Chuck Lever > > > > > > David > > --- > > sunrpc: Use sendmsg(MSG_SPLICE_PAGES) rather then sendpage > > > > When transmitting data, call down into TCP using sendmsg with > > MSG_SPLICE_PAGES to indicate that content should be spliced rather than > > performing sendpage calls to transmit header, data pages and trailer. > > > > Signed-off-by: David Howells > > cc: Trond Myklebust > > cc: Anna Schumaker > > cc: Chuck Lever > > cc: Jeff Layton > > cc: "David S. Miller" > > cc: Eric Dumazet > > cc: Jakub Kicinski > > cc: Paolo Abeni > > cc: Jens Axboe > > cc: Matthew Wilcox > > cc: linux-nfs@vger.kernel.org > > cc: netdev@vger.kernel.org > > --- > > include/linux/sunrpc/svc.h | 11 +++++------ > > net/sunrpc/svcsock.c | 40 +++++++++++++--------------------------- > > 2 files changed, 18 insertions(+), 33 deletions(-) > > > > diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h > > index 877891536c2f..456ae554aa11 100644 > > --- a/include/linux/sunrpc/svc.h > > +++ b/include/linux/sunrpc/svc.h > > @@ -161,16 +161,15 @@ static inline bool svc_put_not_last(struct svc_serv *serv) > > extern u32 svc_max_payload(const struct svc_rqst *rqstp); > > > > /* > > - * RPC Requsts and replies are stored in one or more pages. > > + * RPC Requests and replies are stored in one or more pages. > > * We maintain an array of pages for each server thread. > > * Requests are copied into these pages as they arrive. Remaining > > * pages are available to write the reply into. > > * > > - * Pages are sent using ->sendpage so each server thread needs to > > - * allocate more to replace those used in sending. To help keep track > > - * of these pages we have a receive list where all pages initialy live, > > - * and a send list where pages are moved to when there are to be part > > - * of a reply. > > + * Pages are sent using ->sendmsg with MSG_SPLICE_PAGES so each server thread > > + * needs to allocate more to replace those used in sending. To help keep track > > + * of these pages we have a receive list where all pages initialy live, and a > > + * send list where pages are moved to when there are to be part of a reply. > > * > > * We use xdr_buf for holding responses as it fits well with NFS > > * read responses (that have a header, and some data pages, and possibly > > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c > > index 03a4f5615086..af146e053dfc 100644 > > --- a/net/sunrpc/svcsock.c > > +++ b/net/sunrpc/svcsock.c > > @@ -1059,17 +1059,18 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp) > > svc_xprt_received(rqstp->rq_xprt); > > return 0; /* record not complete */ > > } > > - > > + > > static int svc_tcp_send_kvec(struct socket *sock, const struct kvec *vec, > > int flags) > > { > > - return kernel_sendpage(sock, virt_to_page(vec->iov_base), > > - offset_in_page(vec->iov_base), > > - vec->iov_len, flags); > > + struct msghdr msg = { .msg_flags = MSG_SPLICE_PAGES | flags, }; > > + > > + iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, vec, 1, vec->iov_len); > > + return sock_sendmsg(sock, &msg); > > } > > > > /* > > - * kernel_sendpage() is used exclusively to reduce the number of > > + * MSG_SPLICE_PAGES is used exclusively to reduce the number of > > * copy operations in this path. Therefore the caller must ensure > > * that the pages backing @xdr are unchanging. > > * > > @@ -1109,28 +1110,13 @@ static int svc_tcp_sendmsg(struct socket *sock, struct xdr_buf *xdr, > > if (ret != head->iov_len) > > goto out; > > > > - if (xdr->page_len) { > > - unsigned int offset, len, remaining; > > - struct bio_vec *bvec; > > - > > - bvec = xdr->bvec + (xdr->page_base >> PAGE_SHIFT); > > - offset = offset_in_page(xdr->page_base); > > - remaining = xdr->page_len; > > - while (remaining > 0) { > > - len = min(remaining, bvec->bv_len - offset); > > - ret = kernel_sendpage(sock, bvec->bv_page, > > - bvec->bv_offset + offset, > > - len, 0); > > - if (ret < 0) > > - return ret; > > - *sentp += ret; > > - if (ret != len) > > - goto out; > > - remaining -= len; > > - offset = 0; > > - bvec++; > > - } > > - } > > + msg.msg_flags = MSG_SPLICE_PAGES; > > + iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, xdr->bvec, > > + xdr_buf_pagecount(xdr), xdr->page_len); > > + ret = sock_sendmsg(sock, &msg); > > + if (ret < 0) > > + return ret; > > + *sentp += ret; > > > > if (tail->iov_len) { > > ret = svc_tcp_send_kvec(sock, tail, 0); > > > > -- > Chuck Lever > >