Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp80353pxa; Thu, 13 Aug 2020 20:20:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKpb8/HKCGA6jfZXFPMSg/BoJDqQ19klvF41eKWGcUPAOfxsGfcCK4DnGPawPRqMEkLmxL X-Received: by 2002:a17:906:c34e:: with SMTP id ci14mr547241ejb.335.1597375245912; Thu, 13 Aug 2020 20:20:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597375245; cv=none; d=google.com; s=arc-20160816; b=qr1cJotQzbEt8kw76yLOZhfUjdWvZioE766crGzDSq4s15JJU3+60r6+F6jxvdmCrl 9Z1hygxuxLHhL8tQGZmLhwECUGjvIQ4Gt1fR06RqpUczccDWZTHsLNBBLwf6zQh5MFoU td06jbFIkZZwLnCElGHlqiDKBAED2ZMFGDfHOYSj0iawsurNYrgPqjFT6EJowaOl41na tVgE6p5VMHeuaFmwAcgpBLzyzOzHUflYVgtwcnJtTJhg3K+MgbLmVH9M2++mWMau578S tPmx+Qv8Lo8MYwbnWoSfR87HBwIWhguMqWxSJ33k/B1hLJIG+oFpN0wXdk90gI0Ly3SW VMTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=rBYMDlxTiytCZOnej5NOe0TEBJStDGeKuKqn0WaGAj0=; b=L/Aj8t2d1dxtcCgSPrkgTd7DDVklxR2xVqGE+WaaVs1kUlRV/xLvO4UGcy/bCrzQQn E27kqlfnvvXZjLxV0gBJsW9fgfURHJPmUxr4Cd5BUrKIPM/G5MEuGX31BDSMaZxafgp8 pwjdnQ/ZG9Tos3X1TtmEdtiAAw6OVD8C77JfAFGpIHRQ2RfgtZlxX/E9WGqy4c71iEpN N2aUS82orBDTnXND3ITQu0fyloXs1AQaOzFbsQcyzrCEyGM3KjgRPuCX2eB3geM5w7yU 4CGLcf1v7Ne4nK2pPTtmCNtsSOgqxTA3wiPXifBxNG5VFgK8aeQK6Z1y/hTFs2Yx/+eJ He9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=TTWFAdtB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id kt20si4353137ejb.491.2020.08.13.20.20.21; Thu, 13 Aug 2020 20:20:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=TTWFAdtB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726587AbgHNDTr (ORCPT + 99 others); Thu, 13 Aug 2020 23:19:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726567AbgHNDTq (ORCPT ); Thu, 13 Aug 2020 23:19:46 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3DF2C061757 for ; Thu, 13 Aug 2020 20:19:45 -0700 (PDT) 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=rBYMDlxTiytCZOnej5NOe0TEBJStDGeKuKqn0WaGAj0=; b=TTWFAdtBK1+bVftJ/OqF/azC0M pqwZT+TlfShXxbamW3IjWAiZT++8tBBVcF34m3c1uuD1E7agFUdKic/Se9Riy8MVEV/m01ARuxYnk p61gMHbgTozzBo5D+nQNqCWR2g0z7dYyeAsxRnlckMaUuRNf64dgUsVASm01f8xouKRVxNHicMqqr xoGcDB/Vvaj6sPkQ0HZpXyxJ+3hf2+g4KXbgZ1ExvbpH6cSEqk07SwoIy77xShnHvPucQxDdbn+4m fHHrCxz2e7dldytvaIQWEeePy62h6tiMJAz9OnWwUwW5JBXw6ALSQMsxpKBaDrdepp3v1G9ttkheO MgjXM1VQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k6QFd-0004tP-NA; Fri, 14 Aug 2020 03:19:29 +0000 Date: Fri, 14 Aug 2020 04:19:29 +0100 From: Matthew Wilcox To: Zhaoyang Huang Cc: Andrew Morton , Roman Gushchin , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML Subject: Re: [PATCH] mm : update ra->ra_pages if it's NOT equal to bdi->ra_pages Message-ID: <20200814031929.GV17456@casper.infradead.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 14, 2020 at 10:45:37AM +0800, Zhaoyang Huang wrote: > 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. OK, this is a much more useful description of the problem, thank you! I can think of two possibilities here. One is that maybe our readahead heuristics just don't work on modern phone hardware. Perhaps we need to ramp up more aggressively by default. The other is that maybe it really is just a "boost at startup" kind of situation and so we should support _that_. Some interface where we can set a ra_boost, and then do: if (ra_boost) newsize *= 2; in get_init_ra_size().