Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp963927pxa; Wed, 19 Aug 2020 21:41:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7u4I0y17gW6kcIUEZrA3l+3EnMkVT80xT8S4vU96h2hCWEG8UPbC44Zon9Z270yQ+yWwr X-Received: by 2002:aa7:c50b:: with SMTP id o11mr1147884edq.59.1597898467913; Wed, 19 Aug 2020 21:41:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597898467; cv=none; d=google.com; s=arc-20160816; b=wUHiZEGalhLBKtYZc3k1G04L0aloxpqt8rayy9nkBmFxWskVJGKqZbCZ7y/gWUzokd FKukT2m4lbFGbGo0fr2h225/3JpXj+COLEkiiwAvTNeXfihfcik1aC9gqpZlVgi900r4 LpeEzP6YIt8iqMtUC3JMd+2tjkmvGTlLTI+DQBCr10OPvPEto2lr+NthI/HL2fj+vsZr ndSplIWpC/OARV8um5r7VtgV9va8by+Sk/eWEWG5547Fl1zzSmfj3teIOcolk5WbbfnG nwwP9JrpnxbnVNClGduRjxafjw0I+ca6HjpD7i/1BoB+6hkTfiugTvUi77EQADDhfPP7 P46Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Lxi6/vyaD2y7rAlEJ90F7DFndUPI+sEfNwFAu4abEXg=; b=SkbDQzaL/xA7HHIrHmo2seQy3ZqzJiRGpMeBSVVVxqT5WeHb+UBGjGnTZNYIxENR5H sjXbz5RGbPH/AgBPpv9RyWM16tEC9CNwkFIEydpZCUCNAPYVz2xy0vCSyyX5+MsGWgI2 PLv7udK/f11faBkfs4+3haPQE7pBlbv3Boy8JQvhu7eGys2nl7zer4MuovowO7I+Gsol BgxKvOnZOLr62G9xtUtNGr7qq8tllsnv/lOa/fST7s24D/5npW8KMhciOY1pb8EJe4Cj 6BSfBRrA7T98sgAP3XPxWxW4rz7h+fmYqp5WMps6Q71EEFxhA7SXQrdaClOkgg98TDsy ilxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c21si498722ejm.385.2020.08.19.21.40.43; Wed, 19 Aug 2020 21:41:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726132AbgHTEht (ORCPT + 99 others); Thu, 20 Aug 2020 00:37:49 -0400 Received: from verein.lst.de ([213.95.11.211]:40359 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725772AbgHTEhs (ORCPT ); Thu, 20 Aug 2020 00:37:48 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 2D19E68BEB; Thu, 20 Aug 2020 06:37:45 +0200 (CEST) Date: Thu, 20 Aug 2020 06:37:44 +0200 From: Christoph Hellwig To: David Miller Cc: hch@lst.de, kuba@kernel.org, colyli@suse.de, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: bypass ->sendpage for slab pages Message-ID: <20200820043744.GA4349@lst.de> References: <20200819051945.1797088-1-hch@lst.de> <20200819.120709.1311664171016372891.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200819.120709.1311664171016372891.davem@davemloft.net> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 19, 2020 at 12:07:09PM -0700, David Miller wrote: > Yes this fixes the problem, but it doesn't in any way deal with the > callers who are doing this stuff. > > They are all likely using sendpage because they expect that it will > avoid the copy, for performance reasons or whatever. > > Now it won't. > > At least with Coly's patch set, the set of violators was documented > and they could switch to allocating non-slab pages or calling > sendmsg() or write() instead. > > I hear talk about ABIs just doing the right thing, but when their > value is increased performance vs. other interfaces it means that > taking a slow path silently is bad in the long term. And that's > what this proposed patch here does. If you look at who uses sendpage outside the networking layer itself you see that it is basically block driver and file systems. These have no way to control what memory they get passed and have to deal with everything someone throws at them. So for these callers the requirements are in order of importance: (1) just send the damn page without generating weird OOPSes (2) do so as fast as possible (3) do so without requÑ–ring pointless boilerplate code Any I think the current interface fails these requirements really badly. Having a helper that just does the right thing would really help all of these users, including those currently using raw ->sendpage over kernel_sendpage. If you don't like kernel_sendpage to just do the right thing we could just add another helper, e.g. kernel_sendpage_or_fallback, but that would seem a little pointless to me.