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 EA774C433EF for ; Wed, 13 Apr 2022 18:06:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35B316B0072; Wed, 13 Apr 2022 14:06:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3098D6B0073; Wed, 13 Apr 2022 14:06:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D1296B0074; Wed, 13 Apr 2022 14:06:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 0DCBF6B0072 for ; Wed, 13 Apr 2022 14:06:38 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D2F0725834 for ; Wed, 13 Apr 2022 18:06:37 +0000 (UTC) X-FDA: 79352636034.11.95448B6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id C2A091A000B for ; Wed, 13 Apr 2022 18:06:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RYArLPbSRQE8E13k3ycxmMoQnNRcq1Ic+NpsE4J+dOQ=; b=vMzaRyZmQeJIGHwv1m13Wm5unS s3ZTYmn9U4xKPzk44Q0g/u0dGqXES86OwZ1Ug1FlZ4Gg8SY/4PB8pK+ojDwrwQ+qfVTfcIdStZpCq dn32OxPcKjM/VvEY22ob50yqVN/B7Yow4fnHkU2iVyAgpCu1Fgh71ZP0IztEIy8ibfnA+6BL+YaKB 8+UCXRFsHA1WTfOQRgoML1NAxOSqHgyOW8XqCLYRn+FtSosvkYfDg7Ji22uJvZt/yAJqLxEHNriiS YM1wYeGLasScQ4LaGKJ8/lstaGm1Jk1WfaXWuKJWpoPWU4bZl0nmuks4rHwfP57ywTk+ZF+jmaeJy 78VBzJCg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nehNW-00ESOu-K7; Wed, 13 Apr 2022 18:06:06 +0000 Date: Wed, 13 Apr 2022 19:06:06 +0100 From: Matthew Wilcox To: Christoph Hellwig Cc: Hugh Dickins , 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: Re: making x86 clear_user not suck, was Re: [PATCH] tmpfs: fix regressions from wider use of ZERO_PAGE Message-ID: References: <9a978571-8648-e830-5735-1f4748ce2e30@google.com> <20220409050638.GB17755@lst.de> <20220412045757.GA5131@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220412045757.GA5131@lst.de> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C2A091A000B X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vMzaRyZm; dmarc=none; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: tn6hxn1itmj5ws6y1f3j7cged13o71iy X-HE-Tag: 1649873196-530369 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 Tue, Apr 12, 2022 at 06:57:57AM +0200, Christoph Hellwig wrote: > 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? Apparently that already happened, but it needs finishing up: https://lore.kernel.org/lkml/Yk9yBcj78mpXOOLL@zx2c4.com/