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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 D784EC433DF for ; Fri, 14 Aug 2020 02:45:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9058E20768 for ; Fri, 14 Aug 2020 02:45:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iItyAXbV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9058E20768 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0A95D6B0002; Thu, 13 Aug 2020 22:45:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 059DE6B0003; Thu, 13 Aug 2020 22:45:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E89C96B0005; Thu, 13 Aug 2020 22:45:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id D000B6B0002 for ; Thu, 13 Aug 2020 22:45:49 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 94CF6180AD811 for ; Fri, 14 Aug 2020 02:45:49 +0000 (UTC) X-FDA: 77147634018.12.pet62_5b044df26ff9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 68BEF18002E1A for ; Fri, 14 Aug 2020 02:45:49 +0000 (UTC) X-HE-Tag: pet62_5b044df26ff9 X-Filterd-Recvd-Size: 5282 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Aug 2020 02:45:48 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id g14so9530292iom.0 for ; Thu, 13 Aug 2020 19:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V67boQdxUh+EKnHxjdSvNlWThBzPWn7l76Hn+22xKwY=; b=iItyAXbV4AtTVB/A1XLrODCdqoj3hNd0mtqFqafBesCMzP0JneEhDnMDeck0jmFAh2 VbAlECWw8BvsK7ymoeea0C3gUUroE4/gQy07gHiZoJbCTySpkZsgoB797bTGJRrr2uW/ fe6H+M45kvlp6amw/Zfd1DHOpKYCC1tXxgVbb/GsdcCfKkeMw6Ss8t++Ls6DO552Qfvm HJmwXyFdd1XzHCrxehmBr21bFd+81TrtHuotW0pBYhjBeNNzCdAsRLoftze9H9ld8i4Z sKvdLFvaNsIGnID//lsgKMq5yoO3LlOfh8+rxuASi2lcxpNUZnneJ2TuRZGM7aTPn4E5 VnrQ== 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=V67boQdxUh+EKnHxjdSvNlWThBzPWn7l76Hn+22xKwY=; b=IP+E318wsRiLCKs+2adtO7NWzSQAZOtrKlWQcuSu6Ss44yAxP08g+l8enkz66Ms2c9 +KOgvqJ+8RsZbRj73VbG1bSQCzmKe7YFuwtSDQfv+hMt1yztXNSAFIbJRbmWtcmlPJyW s4U1JbxeXEQDyXz3WuWgM2KtzL9Gy94PUIxAlDlk6n5VPPExWesphUXK0Cmx95LuU4Gn yFGY0V+pbbr1nA3sum4lQQtpJeV+etN5jDVvBeRuDg/RAMEWOtqCOFwZQLNnoTS7G20L MmhcTREzqBZl+mbfQndPVoTHi/SBeeBW9z+MSShwpicXzYZzQqizaaZjxHXZWvhKm24Z Xf0A== X-Gm-Message-State: AOAM530UD3Oh245BfEhtPe3B2AcAnb9aEQF/9y/7iJWpNQHfZwJ1CHMs YaXzayR76ya+4OAXE56Syl4RrF9NIN/7I3ORtsg= X-Google-Smtp-Source: ABdhPJxv78dDDcGjM7FjjbGQA9N/soymYwMvLhLNYrnON0VXAb7bUhjWYnq7xWSjAnw4aa1BnsqNVBpVUFE9CSfeBdM= X-Received: by 2002:a05:6602:2fcf:: with SMTP id v15mr468637iow.78.1597373148326; Thu, 13 Aug 2020 19:45:48 -0700 (PDT) MIME-Version: 1.0 References: <1597368611-7631-1-git-send-email-zhaoyang.huang@unisoc.com> <20200814014355.GS17456@casper.infradead.org> <20200814020700.GT17456@casper.infradead.org> <20200813193307.d5597367b7964d95f63e4580@linux-foundation.org> In-Reply-To: <20200813193307.d5597367b7964d95f63e4580@linux-foundation.org> From: Zhaoyang Huang Date: Fri, 14 Aug 2020 10:45:37 +0800 Message-ID: Subject: Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages To: Andrew Morton Cc: Matthew Wilcox , Roman Gushchin , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 68BEF18002E1A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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, Aug 14, 2020 at 10:33 AM Andrew Morton wrote: > > On Fri, 14 Aug 2020 10:20:11 +0800 Zhaoyang Huang wrote: > > > On Fri, Aug 14, 2020 at 10:07 AM Matthew Wilcox wrote: > > > > > > On Fri, Aug 14, 2020 at 02:43:55AM +0100, Matthew Wilcox wrote: > > > > On Fri, Aug 14, 2020 at 09:30:11AM +0800, Zhaoyang Huang wrote: > > > > > file->f_ra->ra_pages will remain the initialized value since it opend, which may > > > > > be NOT equal to bdi->ra_pages as the latter one is updated somehow(etc, > > > > > echo xxx > /sys/block/dm/queue/read_ahead_kb).So sync ra->ra_pages to the > > > > > updated value when sync read. > > > > > > > > It still ignores the work done by shrink_readahead_size_eio() > > > > and fadvise(POSIX_FADV_SEQUENTIAL). > > > > > > ... by the way, if you're trying to update one particular file's readahead > > > state, you can just call fadvise(POSIX_FADV_NORMAL) on it. > > > > > > If you want to update every open file's ra_pages by writing to sysfs, > > > then just no. We don't do that. > > No, What I want to fix is the file within one process's context keeps > > using the initialized value when it is opened and not sync with new > > value when bdi->ra_pages changes. > > So you're saying that > > echo xxx > /sys/block/dm/queue/read_ahead_kb > > does not affect presently-open files, and you believe that it should do > so? > > I guess that could be a reasonable thing to want - it's reasonable for > a user to expect that writing to a global tunable will take immediate > global effect. I guess. > > But as Matthew says, it would help if you were to explain why this is > needed. In full detail. What operational problems is the present > implementation causing? The real scenario is some system(like android) will turbo read during startup via expanding the readahead window and then set it back to normal(128kb as usual). However, some files in the system process context will keep to be opened since it is opened up and has no chance to sync with the updated value as it is almost impossible to change the files attached to the inode(processes are unaware of these things). we have to fix it from a kernel perspective.