Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp708168rdb; Fri, 2 Feb 2024 01:10:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IEOQUZYOuhADjzJZgjcGpHGu89nEudAnMF58iqHwyA4t/4XvJ2OLdUJ1j2BDC0PBhK0yIDB X-Received: by 2002:a17:90b:3653:b0:296:2e4b:bfdb with SMTP id nh19-20020a17090b365300b002962e4bbfdbmr1643207pjb.8.1706865005041; Fri, 02 Feb 2024 01:10:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706865005; cv=pass; d=google.com; s=arc-20160816; b=qv0tvF8mHCMLVo0LcsjuYAhlGTDHqk5aWFQxmx6oQO/Q+pnf/y/5INODRT9jqJNhiO H1v1dsiF91KdQ9XAl1ngxCKtp+Nfy4zqfHC74q9+fX4FJBUkYaVxRrYtXBRupcoqWgAQ YX/BsTV0BUs27SmXPHSg7c7j13aedpMx7eAT8FUwr3lZ+XdebW6CIPhc46BpWOzODxGm w3fdYToELxTCGBukPApGkp0Cvr4Z+EPIJ+jeESYSMxk0pDnPfKxQfs0wdaIvE1GyygEs 0M0Zo7aSI1Y1N63ZArglFY4o6Jh6gzdATcPVgE/0ExCewWQnJQAw3cgO3R11A8U7nIMT iVfg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:user-agent:date:message-id:from:cc:references:to:subject; bh=poZrDLs1jTj0NpoAiYo4Wcx5ANZl9EM4bU0O/nGuoFs=; fh=sg6NRJXsklGC2sK8MyeXhUNgj6090OjC6z0K+fRZ0x4=; b=QJ26rj/X2JbJNBfd1B48pp08xZAhR853mlhQEhoqcfV79xTYkhnJ1ex7DfmG2F1kXO 7sbh5pJtjALgmX/xCKkd8sFo33Tawno0ogT7RRCZckcPhTnzMzFPKUBTYWP5cxnfP62d UViCfcHhCLDYK0MjCdz5B/YY9JMIcxHPvb23ASXk/Kkcemo3fACPlXNvkUZko0kI05ww dbWsSh9elcTFZJFmX0DxC9wCJpSjUU93md3mqG5jBHSCzkkMTYVM3YtSzPFjUMQYaM1X VgrnUjNJySorgGF9ylsCftXH4h59Fb3IqEHp5ozE349x66k5ViREY0KSWpDrGT1+TTVc M1vw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-49525-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-49525-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com X-Forwarded-Encrypted: i=1; AJvYcCXh4BCcQW2f7pv6/3oEEOYmCkX5JNgQsrImYdSH5kRPLygciOTWXfJVHtoDn12vEDALGVX7m/x8fgym5GFHf7g6ECUodOW7qy6LwKqpag== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id y15-20020a17090a16cf00b00290358165d9si1421031pje.13.2024.02.02.01.10.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 01:10:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-49525-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-49525-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-49525-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 6D1F8281C29 for ; Fri, 2 Feb 2024 09:02:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3C2266BB54; Fri, 2 Feb 2024 09:02:10 +0000 (UTC) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09DCA62162; Fri, 2 Feb 2024 09:02:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706864529; cv=none; b=VUUWh2eb77VZzwCuH396apu01wlEqFk2IqT+p4uK1zBTmpsPwVzFjK2XDqBnvGyz8PdGVBAzBEhF8zeBotKryk3W3A6OjQc497WZwNFU++dMBHH9ytsbSGFXd7xEy/qH69DBD+tk7UH7J7uIdjnJ6iT7xxiO1xKH7SYQN9swHis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706864529; c=relaxed/simple; bh=aHzEmoPoxsCtAcAXqMLjI12v8AWic6XYoYlNqsGWalQ=; h=Subject:To:References:CC:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=ciTAJwlAtgsQe4zonSSVlkWIrzrg3d8TkUt0BLjayZCaxSEEh9wQwQSRTFbbyyDkbKVSZUNqWAA34vL9crScXo0akCVdzi8rx24fW0oD04aeF7/1rkZQcifE4CXoOF/ZIXV5aHN2hhTWVtBrzQuRLMC/iCSqDbUTth21UOZrMCs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20240201173130.frpaqpy7iyzias5j@quack3> Content-Type: multipart/mixed; boundary="------------851C32ACB350EF2108EAD576" X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemd200004.china.huawei.com (7.185.36.141) --------------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--