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 AA5DAC4828D for ; Fri, 2 Feb 2024 01:25:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4693E6B0078; Thu, 1 Feb 2024 20:25:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 423406B007E; Thu, 1 Feb 2024 20:25:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 309506B0080; Thu, 1 Feb 2024 20:25:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1DDD56B007E for ; Thu, 1 Feb 2024 20:25:25 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EC6B61606C5 for ; Fri, 2 Feb 2024 01:25:24 +0000 (UTC) X-FDA: 81745120968.05.1B7D6D5 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf16.hostedemail.com (Postfix) with ESMTP id 2930018000D for ; Fri, 2 Feb 2024 01:25:20 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706837123; 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=UVdQiJ60gHbmO93Db9K/4BPPX7/dsycsTaxf9J1S37c=; b=LmNN1Xv6Civim5ebXOUATBTRNqpwUoIyKTC1B1E6DLAFJuH9f2907kJFosvmnkoxyoSMg/ 68nmiKhVREqqb73vg5mQciq3zi4LE/TWTfng0Q1Nsc/8MRBMbY0Ux0jlkhfNH3H9gdvYsj 8USJXjCC3lIDkq+ZML+zC8LaxHVBEfo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706837123; a=rsa-sha256; cv=none; b=feOQj6nYBbfWcl9h7f5w84Xln+O8oq7rEy5ulIlJjVH0Lm236AIguQ9KxrXqtbjvUPMrZ9 mEUnVPscrZ7ejU4vWQhHcEUzECzTCTdf0obs3qR+rc8ga56RNUvHAogS9Ocw3KCKxqFxTi 2shAuq8Cnf3rXF+HvCowvNm/3IFq1eY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4TQyjV0rxwz1xn6M; Fri, 2 Feb 2024 09:24:14 +0800 (CST) Received: from dggpemd200004.china.huawei.com (unknown [7.185.36.141]) by mail.maildlp.com (Postfix) with ESMTPS id CC7AC140384; Fri, 2 Feb 2024 09:25:15 +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_128_GCM_SHA256) id 15.2.1258.28; Fri, 2 Feb 2024 09:25:15 +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> CC: Alexander Viro , Christian Brauner , Matthew Wilcox , Andrew Morton , , , From: Liu Shixin Message-ID: Date: Fri, 2 Feb 2024 09:25:14 +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: <20240201173130.frpaqpy7iyzias5j@quack3> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemd200004.china.huawei.com (7.185.36.141) X-Rspamd-Queue-Id: 2930018000D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: bhibcjgrgy6r4ukqpi6nnj5q6hehms14 X-HE-Tag: 1706837120-944353 X-HE-Meta: U2FsdGVkX1+910YlP71Op4Lr+KC0TUc5sHxo6LZmh5wDkp9m7jcoG/6ZHTaq1LkpitiPVtDxBPylEpNBONsnkx/mgQBkle5wNxxSMHf+NdIBW42CIskQkydNX6lH712WPy6OOKhu454QbFWYWnelTqyT7Ebupj4Dum+u8TfDkwG3cuesAijsOrAxNO6zcA4giPg/8bUah5fRWXH1FojgT1DM4NRC403WL5Ncjbm5VMXDXGyQcYl7qjfWYODaY5LB3kPC1WU6ju0UWULmuUlRWS+/oX5AELU2Dt8uCnFJwQ7XbBLGYFBW8fJNzFzxiK9xSa5lDIOgLi4OCnaU32xDBUlFqeIUMga7fCPZuKCINaBF6wEXR4BHR/JdAblr+H1913ADmn1z4KJAtM+7w5GxO4G0Fy5r/8Q7IN2nxF2g2nmuKffoksPk8W76PRMgwCoFTjUgeLd4CU67B+6sHomDK5TCJkdP3Oo+oqV8PxX52NxYWEGxku93lXa0czLa1dh2II2bpmrjHYeN7nvD4Xuf3QkTcaBylAYxoQpkXvDebmh15bcw8KGUtcuydgGh2O/taT2qsJHQm0pSA+yvagCfAmWwLKbRhwyAI6ykZ2Jxu0QQznqXS0ChStnE0n7ooWPaEjJqJvKG4E7WW9d2NDCopEIgqBefVPt3huoFllzLS/XSTakR99FoxTepxLGSnfY7CaIypH0yJvlYh83SE6/sKemgMMSNAshhiNvegETzpyejTFICbIhoEUQRpjv4as//bJAuaFAz/0931cVJWZN6K6o2EwbZxKV3cPcVohK29F221XNWhjNoNgYqzH6YGYIErkTS7ArFJlejP8RXLMM1QQiMUSKIMFURku+rJaphD9kl+MEvmSFNKZqJYnkM0QKPX6D0bPuz942ppqHy+JU/R73bpyV2jjirtx9bFapsg7xTmw12kPllhAf6EBqwTqn4o69MM+TjtceSHslvbhG DcYPxM/Y V4fZO+caFCnizxVLYWKkQNWOMp55foyM6fch3tD4NKUG5mNoqBAZ/xF/M7qDfH0nfUMCv+111nw+X0+7b8YIRtN7xAx/gq74yKd92XaMsZCe14qpi0WablKFkKXRfN3K0AtvN1rGlOgugss8fkM2aTlz/0t51eHBYTnln 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 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 Thanks for the patch, I will test it. >