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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 268FCCA9EAF for ; Wed, 30 Oct 2019 07:02:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D11FB20874 for ; Wed, 30 Oct 2019 07:02:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572418957; bh=1yqCg+h4IXZL8j8aQxs51mSz00JxiV5G4EM5WAge67Q=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=mm9xwa/mXYXt8Ac4Xmu+Q8Gfn+zBtNgx8xpOwUUInPACk88KOy5S95og6ek/kCYg9 aannix37Pkyow8SCacO0GFgWsA+Qe8ANkDFz1xW9lr0L0zRGA2NQ4hniTCY/mF3eEr AySxqz+Gs/RqHA1PCgzs/mQbMEv5d89csk1NF32w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727299AbfJ3HCg (ORCPT ); Wed, 30 Oct 2019 03:02:36 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:37843 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbfJ3HCg (ORCPT ); Wed, 30 Oct 2019 03:02:36 -0400 Received: by mail-lj1-f195.google.com with SMTP id v2so1389470lji.4 for ; Wed, 30 Oct 2019 00:02:34 -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=JkPxjSTbXJRVlSsGsdM45+hTs410YbmCCQkse72XJ4Y=; b=EJUY1JQv+QdQjb/gEObNMcJ78C0IhEJfrdoWxqU34kB9i8Bg/sWh/y3mgavhGW/PEq vhD7pUJS4U+vzBOM2zuUAC9zkjBi+8tmMTFlpxoi0FPmyW1RXKur3WY5NqokJ0g4R2wy 7TiXXVvHYhvBEsiZolrKl8XydGUo3K1rzh3Yw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JkPxjSTbXJRVlSsGsdM45+hTs410YbmCCQkse72XJ4Y=; b=n+6UKQCTSG7C2kZuwpwAQLsg5KShxiBi/fk8psjlOzhGC9N/+mibKd2ZoydFTw3HTZ 3wk92kh2xpFN0XPBmz7q6Tq+Ux/prF1nVliS7IHj6bFqEYLV91HBYa6BbvNYMtwAOCwn ots+SMdvCA3g3gQ5GPwnYAbGF+Zc5RxGm/JHjSLUNmU96peXVf5y9qYjE8OiuzMsg9g3 5Siic4fgMYsn8yE3ba9/+mD3TJ5MKus8QYSNcBXpTsnrcJi3tAtsZSh2Pbl7Cme66DBJ smR+3JqaSqOAotJlcEtMmRAn13xXyFhBKRJsG6N8bglC1y2VPkY8YV0Z6Q9MJuQ2+maO BK/Q== X-Gm-Message-State: APjAAAXAFSToVqnNeUdICJ5u33oFeaZnOAf0w0aOBoLOMe6P5SxY3yY8 577bSnhwkYeoP8wQO5I9L/pD7+LFPg+bkA== X-Google-Smtp-Source: APXvYqz4yLVmitgYnJ5F/IiXw5jYtvB70WEMWeVM4SEpfUufsleaWHHGfJiDFK3d5gX9Af1NB273Dg== X-Received: by 2002:a2e:9888:: with SMTP id b8mr4840075ljj.167.1572418953692; Wed, 30 Oct 2019 00:02:33 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id p88sm684246ljp.13.2019.10.30.00.02.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 00:02:31 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id q28so688942lfa.5 for ; Wed, 30 Oct 2019 00:02:31 -0700 (PDT) X-Received: by 2002:ac2:5bca:: with SMTP id u10mr5108158lfn.134.1572418950853; Wed, 30 Oct 2019 00:02:30 -0700 (PDT) MIME-Version: 1.0 References: <157225677483.3442.4227193290486305330.stgit@buzz> <20191028124222.ld6u3dhhujfqcn7w@box> <20191028125702.xdfbs7rqhm3wer5t@box> <20191030065037.o3q6usc5vo3woif6@box> In-Reply-To: <20191030065037.o3q6usc5vo3woif6@box> From: Linus Torvalds Date: Wed, 30 Oct 2019 08:02:14 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read To: "Kirill A. Shutemov" Cc: Konstantin Khlebnikov , Linux-MM , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Johannes Weiner , Steven Whitehouse Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 30, 2019 at 7:50 AM Kirill A. Shutemov wrote: > > I don't know much about filesystems, but can't size of file change after > the open() under network filesystem? Revlidation on read looks like an > requirement anyway, no? Requirement? No. But QoS issue, yes. But note that NFS already does that. Look at nfs_file_read(), and notice how it's not using generic_file_buffered_read() directly, it's doing its own thing first with checking for direct-IO, but then doing that nfs_revalidate_mapping() that checks whether caches should be re-validated. It's not just size of the file, the actual cached contents may need invalidating too etc. And note how the generic page cache reader doesn't need to care. If what the generic code does isn't enough, or is the wrong thing, the filesystem simply shouldn't use it, or, like NFS, do its own thing first/last. So I think the "some filesystems may have other rules" is irrelevant. If they do have other rules, it's _their_ issue, not the issue of the generic page cache read logic. Linus 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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8D33CA9EC4 for ; Wed, 30 Oct 2019 07:02:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7F2BF21734 for ; Wed, 30 Oct 2019 07:02:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="EJUY1JQv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F2BF21734 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 025A16B0003; Wed, 30 Oct 2019 03:02:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F16FC6B0006; Wed, 30 Oct 2019 03:02:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2D206B0007; Wed, 30 Oct 2019 03:02:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C24936B0003 for ; Wed, 30 Oct 2019 03:02:37 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 64D62181AEF21 for ; Wed, 30 Oct 2019 07:02:37 +0000 (UTC) X-FDA: 76099557954.07.goat72_8b34cb5c55e02 X-HE-Tag: goat72_8b34cb5c55e02 X-Filterd-Recvd-Size: 4820 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 07:02:36 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id q28so689087lfa.5 for ; Wed, 30 Oct 2019 00:02:36 -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=JkPxjSTbXJRVlSsGsdM45+hTs410YbmCCQkse72XJ4Y=; b=EJUY1JQv+QdQjb/gEObNMcJ78C0IhEJfrdoWxqU34kB9i8Bg/sWh/y3mgavhGW/PEq vhD7pUJS4U+vzBOM2zuUAC9zkjBi+8tmMTFlpxoi0FPmyW1RXKur3WY5NqokJ0g4R2wy 7TiXXVvHYhvBEsiZolrKl8XydGUo3K1rzh3Yw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JkPxjSTbXJRVlSsGsdM45+hTs410YbmCCQkse72XJ4Y=; b=fK8X+zuRPbFwT1y85hw4CJRkEYaLdWc5TJlXyWm4twnbElkoYGZ+B+Iq28We1HW4HK 4e6tRD0/y6L5jBvoVqbPy06xI3lnqqRzRv5qG69abRhz9bjh5CSvH8nBupAOqAjcuZDR ypPz1m0bXL1W0zXybJio2dlYcoiTWkO03U3eg1yEQP4Efdj9S9myoZw08YytMMeIeMSm jcSD0fwDFojSdyH62AJO+B9BxhCkmz+VVg8BPjb1oxuVD8RB3gGwTqsSPGv8GQYwnifb quE0dpRPnCWIBma0q3efesUeEaEGgMh6nnoWy1xVUBv2amSgVjO5FA6nnR54/g0+71fd NYxA== X-Gm-Message-State: APjAAAX68yxt0sdeQ48igEzx6H2RSrlgKsdmuXxCWT5I681Ruzsgu8JT EkisWm+QWXVU1KuujxIjPmtcNIEm8hGpfg== X-Google-Smtp-Source: APXvYqwioQEtRvURLsH09/TxixTWxzBtCkflS74o2Y1///YDvOFB6ynBdyYebWfVAb7zDcY07AqUQg== X-Received: by 2002:a19:f107:: with SMTP id p7mr4906262lfh.91.1572418953979; Wed, 30 Oct 2019 00:02:33 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id y6sm718775lfj.75.2019.10.30.00.02.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 00:02:31 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id f4so680035lfk.7 for ; Wed, 30 Oct 2019 00:02:31 -0700 (PDT) X-Received: by 2002:ac2:5bca:: with SMTP id u10mr5108158lfn.134.1572418950853; Wed, 30 Oct 2019 00:02:30 -0700 (PDT) MIME-Version: 1.0 References: <157225677483.3442.4227193290486305330.stgit@buzz> <20191028124222.ld6u3dhhujfqcn7w@box> <20191028125702.xdfbs7rqhm3wer5t@box> <20191030065037.o3q6usc5vo3woif6@box> In-Reply-To: <20191030065037.o3q6usc5vo3woif6@box> From: Linus Torvalds Date: Wed, 30 Oct 2019 08:02:14 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read To: "Kirill A. Shutemov" Cc: Konstantin Khlebnikov , Linux-MM , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Johannes Weiner , Steven Whitehouse Content-Type: text/plain; charset="UTF-8" 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 Wed, Oct 30, 2019 at 7:50 AM Kirill A. Shutemov wrote: > > I don't know much about filesystems, but can't size of file change after > the open() under network filesystem? Revlidation on read looks like an > requirement anyway, no? Requirement? No. But QoS issue, yes. But note that NFS already does that. Look at nfs_file_read(), and notice how it's not using generic_file_buffered_read() directly, it's doing its own thing first with checking for direct-IO, but then doing that nfs_revalidate_mapping() that checks whether caches should be re-validated. It's not just size of the file, the actual cached contents may need invalidating too etc. And note how the generic page cache reader doesn't need to care. If what the generic code does isn't enough, or is the wrong thing, the filesystem simply shouldn't use it, or, like NFS, do its own thing first/last. So I think the "some filesystems may have other rules" is irrelevant. If they do have other rules, it's _their_ issue, not the issue of the generic page cache read logic. Linus