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 401C8C433FE for ; Fri, 15 Apr 2022 22:11:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0FC06B0072; Fri, 15 Apr 2022 18:11:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBE176B0073; Fri, 15 Apr 2022 18:11:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A86646B0074; Fri, 15 Apr 2022 18:11:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 9A70D6B0072 for ; Fri, 15 Apr 2022 18:11:12 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9EC3225FA1 for ; Fri, 15 Apr 2022 22:11:12 +0000 (UTC) X-FDA: 79360509984.08.4C8DBFD Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf08.hostedemail.com (Postfix) with ESMTP id E660A160003 for ; Fri, 15 Apr 2022 22:11:11 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id bj36so4863834ljb.13 for ; Fri, 15 Apr 2022 15:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2QtVXGfSn2N0rkhidefIOm+8RgDS4TB5h/qBI4Eiy4c=; b=QrGEuSyR0q+jdL2W8Yhgv/l15leR2PlJ+RE69Nk92ZEWjEl8top7q6+TqI0Qpj6GaE U9roWFN8VsX0OCnyj8L6IV78ggtpLzOOecvtS+46P4uqkAm4b5Zn2f4Ld/hwOYNyPxl3 +GyIq814tNewte+DEdt9Cb/wYaupvpSLtaywU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2QtVXGfSn2N0rkhidefIOm+8RgDS4TB5h/qBI4Eiy4c=; b=zkFscaxmqn0lj963Se0Od+Viy8r6lMT9E6eymFhPh0lxPIkF8fA4Mkjd3qbKH5ybXX JjKeWgtQ5qzvnS9sChhgnGNZDkYjA89wYgmVbcRt/Mqr8sccnsZlNRWvwwXwXWf6cgvn lquy3fJ4KJ1ULCanrsihqrfW5o8eltsrWbz6wzckVz61cQA9yXEb9ai6v/evOYzxLSTF IrYA9H0klno685HZBQLsJp77LxkRiynzGVSnMF+F8FY5GaKEQltyvm8JGzvCBuvhmAQi FNC8G9nUlHm4Je2dX6oFHYAnoGL6dMhlasAwVP5dSfjvsTSp2NUmtLL29TgdE/let5OK s/EQ== X-Gm-Message-State: AOAM5306n0K1JpVDCPAbWme/m00x4Oj3V3nklDEEYEZtgxLJR2/GW4yO l7zwGQ/f8o/EDFwuBL/hkzRuo3uwC63TOsySlBA= X-Google-Smtp-Source: ABdhPJzvBPyBcpwu0jTCUNlC8jkRniJLHexElrysdX4oahRHbtc9o+KitJfCYpEQIkEAPmlVDa/G9A== X-Received: by 2002:a2e:a726:0:b0:24b:63a6:bd27 with SMTP id s38-20020a2ea726000000b0024b63a6bd27mr599922lje.132.1650060670007; Fri, 15 Apr 2022 15:11:10 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id w8-20020a05651c118800b0024cfc30001dsm399248ljo.49.2022.04.15.15.11.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Apr 2022 15:11:08 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id x17so15807604lfa.10 for ; Fri, 15 Apr 2022 15:11:07 -0700 (PDT) X-Received: by 2002:a05:6512:3c83:b0:46d:452:5096 with SMTP id h3-20020a0565123c8300b0046d04525096mr653490lfv.542.1650060667675; Fri, 15 Apr 2022 15:11:07 -0700 (PDT) MIME-Version: 1.0 References: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> <20220415021328.7D31EC385A1@smtp.kernel.org> In-Reply-To: <20220415021328.7D31EC385A1@smtp.kernel.org> From: Linus Torvalds Date: Fri, 15 Apr 2022 15:10:51 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 02/14] tmpfs: fix regressions from wider use of ZERO_PAGE To: Andrew Morton , "the arch/x86 maintainers" , Peter Zijlstra , Borislav Petkov Cc: patrice.chotard@foss.st.com, Mikulas Patocka , markhemm@googlemail.com, Lukas Czerner , Christoph Hellwig , "Darrick J. Wong" , Chuck Lever , Hugh Dickins , patches@lists.linux.dev, Linux-MM , mm-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=QrGEuSyR; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.182 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: h9o31kspbogsrdujtus9xrh9cf5ei114 X-Rspamd-Queue-Id: E660A160003 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1650060671-452937 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 Thu, Apr 14, 2022 at 7:13 PM Andrew Morton wrote: > > Revert shmem_file_read_iter() to using ZERO_PAGE for holes only when > iter_is_iovec(); in other cases, use the more natural iov_iter_zero() > instead of copy_page_to_iter(). We would use iov_iter_zero() throughout, > but the x86 clear_user() is not nearly so well optimized as copy to user > (dd of 1T sparse tmpfs file takes 57 seconds rather than 44 seconds). Ugh. I've applied this patch, but honestly, the proper course of action should just be to improve on clear_user(). If it really is important enough that we should care about that performance, then we just should fix clear_user(). It's a very odd special thing right now (at least on x86-64) using some strange handcrafted inline asm code. I assume that 'rep stosb' is the fastest way to clear things on modern CPU's that have FSRM, and then we have the usual fallbacks (ie ERMS -> "rep stos" except for small areas, and probably that "store zeros by hand" for older CPUs). Adding PeterZ and Borislav (who seem to be the last ones to have worked on the copy and clear_page stuff respectively) and the x86 maintainers in case somebody gets the urge to just fix this. Because memory clearing should be faster than copying, and the thing that makes copying fast is that FSRM and ERMS logic (the whole "manually unrolled copy" is hopefully mostly a thing of the past and we can consider it legacy) Linus