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 86810C4828E for ; Fri, 2 Feb 2024 09:02:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F9006B0075; Fri, 2 Feb 2024 04:02:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AC496B0078; Fri, 2 Feb 2024 04:02:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 075A76B007B; Fri, 2 Feb 2024 04:02:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EA8AE6B0075 for ; Fri, 2 Feb 2024 04:02:09 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BB835A0E87 for ; Fri, 2 Feb 2024 09:02:09 +0000 (UTC) X-FDA: 81746271978.04.E96E3D4 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf13.hostedemail.com (Postfix) with ESMTP id 8DD722001F for ; Fri, 2 Feb 2024 09:02:06 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.188 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=1706864528; 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: in-reply-to:in-reply-to:references:references; bh=poZrDLs1jTj0NpoAiYo4Wcx5ANZl9EM4bU0O/nGuoFs=; b=2CemwItLAqVVYTQs/PIhcdylVBNTp32cKAduq3ggR3giVmrFE/0eOYDDp+lUXZbz8rff/1 dG/3qXwH3vu3V9S3qgbKhr5L+lOB+xAJLdAzpOZHQO4vi62xOncuTtJvayB0I/3FzY/mew SiRdb4ce2R94Kt33tEDWlk7E60w1yPQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706864528; a=rsa-sha256; cv=none; b=JLh3+y3p5PCjh9Xsi+EIZCY3xtOLRProRx11+/GSHFlPRN06zGEJVHnp0Av2ByevjEIpRh 9sOB38Uckkhqlzc9MQGEECgTrVYNyCQR0rCDH4iXjnE+uh1vGFCi2exLHaC9nSorN+in67 QhnMClUDQf8eLnZYvuYHv+GFZHZDQXY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4TR8r34knvzXh7G; Fri, 2 Feb 2024 17:00:35 +0800 (CST) Received: from dggpemd200004.china.huawei.com (unknown [7.185.36.141]) by mail.maildlp.com (Postfix) with ESMTPS id 688AD140114; Fri, 2 Feb 2024 17:02:01 +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 17:02:00 +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: <78ee0c12-e706-875d-2baf-cb51dea9cfc4@huawei.com> Date: Fri, 2 Feb 2024 17:02:00 +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: multipart/mixed; boundary="------------851C32ACB350EF2108EAD576" X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemd200004.china.huawei.com (7.185.36.141) X-Stat-Signature: hks9nkt4wt4fherb999gzzc478j3e3xg X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8DD722001F X-Rspam-User: X-HE-Tag: 1706864526-254904 X-HE-Meta: U2FsdGVkX1+hsCf1rBHMng9mw6qXmP7hI2R4RJ9aARptvyklcL0dwBUPQaOdc4fnk3xArkQU4gb95xuVnLKI323jmecKIEMtKZfao3f8LXsuBDt1oN4ZxRaj0MFw4YYBduTXo7MIr+XPOqJbB3fMKcFFSQY/uS+CETPbqWbBZLqIbEkIsK5myQptJwHJ61XTLP+AX395nuo0SBVuqmcePfMlAQZQnItT6aMAX9no/vZQJM4G0spM9YuFZG6BOjlcrPp8VvD+6CMGpjJZUc26x7FhWdfmxQ3cGO+5PyFPPjkPtCY4kEp84Sjl6Yc+FZQnSrsNQsLYghLdAGidkFIjV+kBuFzcSL8Lh9KTZ0eN/AXsPZlR90w4V0KemF3j27UvOjXilu4drojqhuqCt3u+GpvFRtO+AV45gEmwF12ASeYNDNCSePQJ5cy+DdajNQNnLee1evgzIqmz1GiEEblfr8VlsWb9W6dNlRQPFAX2qlxxvehZSI4KDskl3qCs7w1rUMYp5llhyHLj7gZWyhIGt6n6uSQJkyjgPj8zsDr8qPfO+YMKdkXNDU53RNtG5HsCI7B5GKTfwp8/OA7pbpzMuIHBbs/gEOpqjLqS9603t1ybtM58mm9wffSd6xuF+4be17anewj9CJADCV1dGS0FOJROWPxZZBu6lyoCKlAPx3RhDi2/XBKNyzfsDRImE/wQMm0qtB0aiPASvT9rgeELfEidnm4y15G76I86AAR0dcsWMDT/zrRlL6LOd0eBwipJXgGedNBOIttIDGJZxVD9adqUfIDwDrOlb9rzO5veR8ifGVJLuzCzZAXXwHflOPenWSBX/hdfzNdOJDgz5dRSkGeaTUsS2ojdPCH7yyQ0FN3SK1BJ3JGqH9KNrOxbtlL4UYwQXJgIgy9YgOpz5mNW7rikRhxLWOeHctyWACfwvqr/Y9iMW/8v1bGim2exTuVsgfCwSg/3D5gATIE8c0F H7NtP8du 8WYfMb46gdQal+B8PW7fbbTSmx+O+K9F/tsyn6ozh1Jkl1ZO77aCNZXHBMLQjPpZI5zPRKXEeK0wRczeM2/lnasRNM73a1piFS4qx3zvyst8fzlQUb3VLMDKk7Gk31cvkkOOPQ1XicMNBPnH+mxjBxpSUG1TXBdv5Vqk/h7aYgAXhLg4fzf4jJPSnDaFa5dTfxXNbcs+groJlrzDA7pmnvw6W2CgepTMSMTvX5QGLsZ1+CpywduJ731Vrca6rOjT7jtTBJInBa1e6ThQkQJlTS7PBH+US4N9+613TC4NqWOxbQc1AqONi+21jY9c77eyRU62er53JwoG16Ts1flUouPwcAE06jzS28oqGHy5V21UY6znTvqTQiyhpvC1aW0mrghsrQ0XG8TgbyR96Mw3XrRSyatIupJhtU0y8 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: --------------851C32ACB350EF2108EAD576 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit 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, > --------------851C32ACB350EF2108EAD576 Content-Type: text/plain; charset="UTF-8"; name="test.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.sh" #!/bin/bash while true; do flag=$(ps -ef | grep -v grep | grep alloc_page| wc -l) if [ "$flag" -eq 0 ]; then /alloc_page & fi sleep 30 start_time=$(date +%s) yum install -y expect > /dev/null 2>&1 end_time=$(date +%s) elapsed_time=$((end_time - start_time)) echo "$elapsed_time seconds" yum remove -y expect > /dev/null 2>&1 done --------------851C32ACB350EF2108EAD576 Content-Type: text/plain; charset="UTF-8"; name="alloc_page.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="alloc_page.c" #include #include #include #include #define SIZE 1*1024*1024 //1M int main() { void *ptr = NULL; int i; for (i = 0; i < 1024 * 6 - 50;i++) { ptr = (void *) malloc(SIZE); if (ptr == NULL) { printf("malloc err!"); return -1; } memset(ptr, 0, SIZE); } sleep(99999); free(ptr); return 0; } --------------851C32ACB350EF2108EAD576--