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 E493DC47DDF for ; Thu, 1 Feb 2024 10:41:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 734876B0074; Thu, 1 Feb 2024 05:41:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E53D6B0075; Thu, 1 Feb 2024 05:41:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5ADEA6B0078; Thu, 1 Feb 2024 05:41:40 -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 486966B0074 for ; Thu, 1 Feb 2024 05:41:40 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 10FE61A062C for ; Thu, 1 Feb 2024 10:41:40 +0000 (UTC) X-FDA: 81742893960.07.6FF16B7 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf25.hostedemail.com (Postfix) with ESMTP id 18C51A0011 for ; Thu, 1 Feb 2024 10:41:35 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf25.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=1706784098; 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=bc5gfVbOXxT+sq8UAqiefMawvRwcgu69TUc2bTaKHL8=; b=nAejCRPjkIlzqbBvM5nE9m2L9zpIavF0J1jloVxkXorVpjewbRkEWGS4rVqeeqEPzh73g+ 1aB5Ipjo43pN2eatUDZt5S/ByOjLnolaYTBD6KKjvav63PuKPvoKfKjvQ5FRUFYUV/l15A LlpzCIlFnGgwNMoRmRTOhOQfdVjGrmk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf25.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=1706784098; a=rsa-sha256; cv=none; b=KT23yRyp4DHfOUX9KjH1oeCQ7fbb3KEXjfLXFKSiZJ6IcG9z6efEyu54ycAqfCkGjbLvV/ 6jhVBVhE1WeW8w48+rwTn5Tpq6/lRXLzEiMZIKpqxaEV40l8w5H0EvnQ98ZRoRb+e4Vb2A QNxeK5qqcZUhBFtTwBbVhtZv6g1Ab3A= Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4TQb4q61Pqz29kyQ; Thu, 1 Feb 2024 18:39:39 +0800 (CST) Received: from dggpemd200004.china.huawei.com (unknown [7.185.36.141]) by mail.maildlp.com (Postfix) with ESMTPS id 2D38C1400D4; Thu, 1 Feb 2024 18:41:31 +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; Thu, 1 Feb 2024 18:41:30 +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> CC: Alexander Viro , Christian Brauner , Matthew Wilcox , Andrew Morton , , , From: Liu Shixin Message-ID: Date: Thu, 1 Feb 2024 18:41:30 +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: <20240201093749.ll7uzgt7ixy7kkhw@quack3> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemd200004.china.huawei.com (7.185.36.141) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 18C51A0011 X-Stat-Signature: c1t7ypqhennikq86e16i9aq6bkg3tnd1 X-Rspam-User: X-HE-Tag: 1706784095-311751 X-HE-Meta: U2FsdGVkX1+dCuDJFgCtjn82aSAAo3A4IjiORCn/i5hSOLLQKeYlIVQKyrPtPZU88KCcOqzfBX2aOTr3upLP1ETumcU0dkKedWPUggl6jnjc/4xWyzuZroCt29sbXQjV5flxiZvKq1mfaI4rJPMvFgFUnNapnP+D8coAFD+9iV52OH7jybNjEdHz2dccE78y7LexWkB2ZElrctiuC38UZ0Imdaacb9dJX7L4ncNIO5rxtgA8akSKtn/OXN/AMbFExzlq3GXcwSnI8UFO/WxAXu0Rfq1706GpyTzxnqgo7pFT+4+CqXd1L8sq3YOFEAGSeOPBy/AW5E6tJ3Zm1V+0nzcv4YfJodZ0DU2lupo6tQ66fIEpaP0bjCqstyuZJl1QrWKJ7akfKazQ3D+gpdVDOblN/Dj69W3QDZ2BJjMO5O3FYHzOcmCPPosMxZ6rdFUpMu8CD+iOtqjr1P3ZGNnIdJMIru8Q7U+XOMwrCKpVHY1jMRa92GljmEsxN96xpBYHoHJaoPxytnaOP9kvbWYxuCFzQn+Z36y4bUWXuL62E2WwlvPsDJF/Q9ljzea8VKmAvoYaSqIZqscox+8jWY5MN7KW5+5ARw1gPivw1frylKjZxawXSTKLN9ftJa6fsWxv7GUEtExqzVJ21s8GNzwBZeePGILxx9DOgHqdX19+6xaeV31N55PnSekigGpC2ZbaTvSnAGiUHYnPvrFJQSGmyuHmMZGj6XIC8RXW3R6mTAGdwHw7vxMXqHAHbG4AxQCUwuGcxdbr0mGVpD5yhnojJbhkY6EclTN3ZJvRmRkUkk6k0NcuRhQ4oDLZoYnCPFeymiX5vM13tnff/+EG9/imGAkM7B65UIhcfIzVEOlnlM8PXMoBnmVCdmFEdJc70EzNDoXxgfZQNX0ttU5Gi/U1+fGr5elD0UGFPX/s1b+0eU05mFkjs5Gzt/5L+OO7zKChn+9hMnhmTZ9VFje3Tkb hP8t05UH cMaydsKgVaSxPZhZ5KXIa3P2HOWkpWjofj/qFN7gOPwCp4rJtT6mlAmglmRE6hr3ABFbxckMuBtHT+Iq6LRjUODvT5h60oWaeWctWO/qPTNGOOmQTxDwU+RlI3iueBh5RRMp/ewstqpds6TmSdxh6bqKilNmhX9P2rGW6 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/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. Thanks, > >> --- >> include/linux/fs.h | 2 ++ >> include/linux/pagemap.h | 1 + >> mm/filemap.c | 16 ++++++++++++++++ >> mm/readahead.c | 4 ++++ >> 4 files changed, 23 insertions(+) >> >> diff --git a/include/linux/fs.h b/include/linux/fs.h >> index ed5966a704951..f2a1825442f5a 100644 >> --- a/include/linux/fs.h >> +++ b/include/linux/fs.h >> @@ -960,6 +960,7 @@ struct fown_struct { >> * the first of these pages is accessed. >> * @ra_pages: Maximum size of a readahead request, copied from the bdi. >> * @mmap_miss: How many mmap accesses missed in the page cache. >> + * @active_refault: Number of active page refault. >> * @prev_pos: The last byte in the most recent read request. >> * >> * When this structure is passed to ->readahead(), the "most recent" >> @@ -971,6 +972,7 @@ struct file_ra_state { >> unsigned int async_size; >> unsigned int ra_pages; >> unsigned int mmap_miss; >> + unsigned int active_refault; >> loff_t prev_pos; >> }; >> >> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h >> index 2df35e65557d2..da9eaf985dec4 100644 >> --- a/include/linux/pagemap.h >> +++ b/include/linux/pagemap.h >> @@ -1256,6 +1256,7 @@ struct readahead_control { >> pgoff_t _index; >> unsigned int _nr_pages; >> unsigned int _batch_count; >> + unsigned int _active_refault; >> bool _workingset; >> unsigned long _pflags; >> }; >> diff --git a/mm/filemap.c b/mm/filemap.c >> index 750e779c23db7..4de80592ab270 100644 >> --- a/mm/filemap.c >> +++ b/mm/filemap.c >> @@ -3037,6 +3037,7 @@ loff_t mapping_seek_hole_data(struct address_space *mapping, loff_t start, >> >> #ifdef CONFIG_MMU >> #define MMAP_LOTSAMISS (100) >> +#define ACTIVE_REFAULT_LIMIT (10000) >> /* >> * lock_folio_maybe_drop_mmap - lock the page, possibly dropping the mmap_lock >> * @vmf - the vm_fault for this fault. >> @@ -3142,6 +3143,18 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf) >> if (mmap_miss > MMAP_LOTSAMISS) >> return fpin; >> >> + ractl._active_refault = READ_ONCE(ra->active_refault); >> + if (ractl._active_refault) >> + WRITE_ONCE(ra->active_refault, --ractl._active_refault); >> + >> + /* >> + * If there are a lot of refault of active pages in this file, >> + * that means the memory reclaim is ongoing. Stop bothering with >> + * read-ahead since it will only waste IO. >> + */ >> + if (ractl._active_refault >= ACTIVE_REFAULT_LIMIT) >> + return fpin; >> + >> /* >> * mmap read-around >> */ >> @@ -3151,6 +3164,9 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf) >> ra->async_size = ra->ra_pages / 4; >> ractl._index = ra->start; >> page_cache_ra_order(&ractl, ra, 0); >> + >> + WRITE_ONCE(ra->active_refault, ractl._active_refault); >> + >> return fpin; >> } >> >> diff --git a/mm/readahead.c b/mm/readahead.c >> index cc4abb67eb223..d79bb70a232c4 100644 >> --- a/mm/readahead.c >> +++ b/mm/readahead.c >> @@ -263,6 +263,10 @@ void page_cache_ra_unbounded(struct readahead_control *ractl, >> folio_set_readahead(folio); >> ractl->_workingset |= folio_test_workingset(folio); >> ractl->_nr_pages++; >> + if (unlikely(folio_test_workingset(folio))) >> + ractl->_active_refault++; >> + else if (unlikely(ractl->_active_refault)) >> + ractl->_active_refault--; >> } >> >> /* >> -- >> 2.25.1 >>