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 77E36C48BF6 for ; Thu, 29 Feb 2024 09:02:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FBBE6B00BB; Thu, 29 Feb 2024 04:02:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AC6B6B00C0; Thu, 29 Feb 2024 04:02:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB68D6B00C1; Thu, 29 Feb 2024 04:02:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DB6256B00BB for ; Thu, 29 Feb 2024 04:02:00 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A47F61C15D6 for ; Thu, 29 Feb 2024 09:02:00 +0000 (UTC) X-FDA: 81844249200.09.81A27D8 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf16.hostedemail.com (Postfix) with ESMTP id 2740A180013 for ; Thu, 29 Feb 2024 09:01:57 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709197319; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0bt2Qunmx/wX0qIFAGXJEKckXlRytGWcfDwiZY1I7Ro=; b=JfhK6QIxCuIJyz1h0tZIDPJ8ffLNyHExn2cj0ofU3NCWMmRDV8CpRlJy4K0QuMeUO89NqH 5o4UdMQ2mRyiFl0evbz7MpMPEgJnfVoRGTuOB/hBdS/6PiZyUhuZuMBwkuJp7anipY7N3o jOpJeGr9CE4pF98psxjVURyyEKd6fZI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=liushixin2@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709197319; a=rsa-sha256; cv=none; b=hwa/YGckmAbbsT7e4jMgentIktEPEo6lYqM8dx9BrQu9vp68ykI16QXmANJXjnWalUzU9m 0+wgc6/OBDrEOJA87u1Dc0XrTvhpanKZMkckYNAB6bGoxYXLQtMdOZ+XMyWwlwC2uGuVpx Wvpn2xo0ljrc9Mf+7dK7nWHMqTW5o8E= Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4TllYJ2Vfdz1xpnW; Thu, 29 Feb 2024 17:00:20 +0800 (CST) Received: from dggpemd200004.china.huawei.com (unknown [7.185.36.141]) by mail.maildlp.com (Postfix) with ESMTPS id 7ECDE140416; Thu, 29 Feb 2024 17:01:51 +0800 (CST) Received: from [10.174.179.24] (10.174.179.24) by dggpemd200004.china.huawei.com (7.185.36.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Thu, 29 Feb 2024 17:01:50 +0800 Subject: Re: [PATCH 2/2] mm/readahead: limit sync readahead while too many active refault To: Jan Kara References: <20240201100835.1626685-1-liushixin2@huawei.com> <20240201100835.1626685-3-liushixin2@huawei.com> <20240201093749.ll7uzgt7ixy7kkhw@quack3> <20240201173130.frpaqpy7iyzias5j@quack3> <78ee0c12-e706-875d-2baf-cb51dea9cfc4@huawei.com> CC: Alexander Viro , Christian Brauner , Matthew Wilcox , Andrew Morton , , , From: Liu Shixin Message-ID: <0ea62dea-94d1-a387-a527-5b0aa0a5fba6@huawei.com> Date: Thu, 29 Feb 2024 17:01:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <78ee0c12-e706-875d-2baf-cb51dea9cfc4@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemd200004.china.huawei.com (7.185.36.141) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2740A180013 X-Stat-Signature: 11eyqjw4cwo7k6hmnk5shrk6wc6he134 X-HE-Tag: 1709197317-722005 X-HE-Meta: U2FsdGVkX192I9oORel6dsaqHLb2NJ/QLJ1cKgdWd6u7VPIw3WcPYqM1y4XKMVXUxpj/0DAgtqvdAt+QpslFB2HklwT9jMygxnFAwqvnbfLaKdkgwiuW23zl7GeT/KT0WJeK5J9ntmooOjhSZL70xvKUo7YQzyOxP1ZPdNxwRQ0YPw5Cg5P5XKWB5VCn22XcAUjK34xH1l2E3KMoX6F1DvCq/d7AXY5yVVSeUX4U7bGe22eHBEV2mN8A3gdjZhsD4dlAOXTjzqaSij3MCY7VIx6i7iPlKuphCwtd3mpOcm+F2mpXRU5wkE9sOE0YuQ8RYiCh73KOzMBmFxpJGqir2Y73xci3PIjAt0TrTkyOk1ikn2pAU/OQQQ2G6Z7/5pvEVqO73QKjU0Exs0PknmctTgf4gDtdlEPCQDFtWLQlbRL8A/ONdqH5g+UeZXPcXaO/AMogBpZ8T9YMK0jzuAbxYhuD6FbjKkvSVihar1THqMVLm+ro/jfVIMbZXSKRg1D+z8wVFLlFeoOfAxxJa0U6VlYRhx7OYGIg/sru2hjbvpwm/hb01a7/AQaocNZaD4/ksQbtTpNimGeYjZK1hpw3SCYpc12hEUOQwBMCDD3UYnumXtkU1mcBlBEOK4qqBb+WO2l3D4zp4UwTlz+e28zubW+1kF2d5nAaqVNGBfTHmbGz20K0xkuaaB22tK4HmOO4a9bAMUUsZUp55jjglNzISqZrMLKmtGqVJ6rV/+MJUWRxB/gTlj2ar6CBB1dFpq2liwz7mIWKojgLjXUsObs0PrcgsTgbi01fbtoaNbi89JISOL7f1AKdtQ== 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: List-Subscribe: List-Unsubscribe: On 2024/2/2 17:02, Liu Shixin wrote: > > On 2024/2/2 1:31, Jan Kara wrote: >> On Thu 01-02-24 18:41:30, Liu Shixin wrote: >>> On 2024/2/1 17:37, Jan Kara wrote: >>>> On Thu 01-02-24 18:08:35, Liu Shixin wrote: >>>>> When the pagefault is not for write and the refault distance is close, >>>>> the page will be activated directly. If there are too many such pages in >>>>> a file, that means the pages may be reclaimed immediately. >>>>> In such situation, there is no positive effect to read-ahead since it will >>>>> only waste IO. So collect the number of such pages and when the number is >>>>> too large, stop bothering with read-ahead for a while until it decreased >>>>> automatically. >>>>> >>>>> Define 'too large' as 10000 experientially, which can solves the problem >>>>> and does not affect by the occasional active refault. >>>>> >>>>> Signed-off-by: Liu Shixin >>>> So I'm not convinced this new logic is needed. We already have >>>> ra->mmap_miss which gets incremented when a page fault has to read the page >>>> (and decremented when a page fault found the page already in cache). This >>>> should already work to detect trashing as well, shouldn't it? If it does >>>> not, why? >>>> >>>> Honza >>> ra->mmap_miss doesn't help, it increased only one in do_sync_mmap_readahead() >>> and then decreased one for every page in filemap_map_pages(). So in this scenario, >>> it can't exceed MMAP_LOTSAMISS. >> I see, OK. But that's a (longstanding) bug in how mmap_miss is handled. Can >> you please test whether attached patches fix the trashing for you? At least >> now I can see mmap_miss properly increments when we are hitting uncached >> pages... Thanks! >> >> Honza > The patch doesn't seem to have much effect. I will try to analyze why it doesn't work. > The attached file is my testcase. > > Thanks, I think I figured out why mmap_miss doesn't work. After do_sync_mmap_readahead(), there is a __filemap_get_folio() to make sure the page is ready. Then, it is ready too in filemap_map_pages(), so the mmap_miss will decreased once. mmap_miss goes back to 0, and can't stop read-ahead. Overall, I don't think mmap_miss can solve this problem. .