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 794E9C433F5 for ; Tue, 12 Apr 2022 04:58:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E10526B0071; Tue, 12 Apr 2022 00:58:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D99006B0073; Tue, 12 Apr 2022 00:58:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C60D16B0074; Tue, 12 Apr 2022 00:58:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id B39BA6B0071 for ; Tue, 12 Apr 2022 00:58:03 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6E246A62F1 for ; Tue, 12 Apr 2022 04:58:03 +0000 (UTC) X-FDA: 79347020046.31.7A56B05 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf22.hostedemail.com (Postfix) with ESMTP id BA09FC0002 for ; Tue, 12 Apr 2022 04:58:02 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 4103168AA6; Tue, 12 Apr 2022 06:57:58 +0200 (CEST) Date: Tue, 12 Apr 2022 06:57:57 +0200 From: Christoph Hellwig To: Hugh Dickins Cc: Christoph Hellwig , Andrew Morton , Chuck Lever III , Mark Hemment , Patrice CHOTARD , Mikulas Patocka , Lukas Czerner , "Darrick J. Wong" , "Jason A. Donenfeld" , Borislav Petkov , linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, viro@zeniv.linux.org.uk, x86@kernel.org Subject: making x86 clear_user not suck, was Re: [PATCH] tmpfs: fix regressions from wider use of ZERO_PAGE Message-ID: <20220412045757.GA5131@lst.de> References: <9a978571-8648-e830-5735-1f4748ce2e30@google.com> <20220409050638.GB17755@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=none; spf=none (imf22.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: BA09FC0002 X-Stat-Signature: 8tfwpf7xmzuu763ofs33gdy3sf54muan X-HE-Tag: 1649739482-884105 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: On Fri, Apr 08, 2022 at 11:08:29PM -0700, Hugh Dickins wrote: > > > > Either way I'd rather do this optimization in iov_iter_zero rather > > than hiding it in tmpfs. > > Let's see what others say. I think we would all prefer clear_user() to be > enhanced, and hack around it neither here in tmpfs nor in iov_iter_zero(). > But that careful work won't get done by magic, nor by me. I agree with that. > And iov_iter_zero() has to deal with a wider range of possibilities, > when pulling in cache lines of ZERO_PAGE(0) will be less advantageous, > than in tmpfs doing a large dd - the case I'm aiming not to regress here > (tmpfs has been copying ZERO_PAGE(0) like this for years). Maybe. OTOH I'd hate to have iov_iter_zero not used much because it sucks too much. So how can we entice someone with the right knowledge to implement a decent clear_user for x86?