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 51C74C433EF for ; Sun, 24 Apr 2022 11:17:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DB876B0074; Sun, 24 Apr 2022 07:17:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 98B4F6B0075; Sun, 24 Apr 2022 07:17:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 852DD6B0078; Sun, 24 Apr 2022 07:17:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 759766B0074 for ; Sun, 24 Apr 2022 07:17:19 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 40AF628926 for ; Sun, 24 Apr 2022 11:17:19 +0000 (UTC) X-FDA: 79391521398.04.7814F28 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf26.hostedemail.com (Postfix) with ESMTP id 964CF140029 for ; Sun, 24 Apr 2022 11:17:16 +0000 (UTC) Received: from kwepemi100014.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KmQb12W3FzhYRH; Sun, 24 Apr 2022 19:17:01 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by kwepemi100014.china.huawei.com (7.221.188.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sun, 24 Apr 2022 19:17:15 +0800 Received: from huawei.com (10.175.124.27) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sun, 24 Apr 2022 19:17:14 +0800 From: Guo Xuenan To: CC: , , , , Subject: Questions about folio allocation. Date: Sun, 24 Apr 2022 19:35:43 +0800 Message-ID: <20220424113543.456342-1-guoxuenan@huawei.com> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.175.124.27] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 964CF140029 X-Stat-Signature: cuyarjdhj4z68ngjp8nmui4d1p1ucds5 Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf26.hostedemail.com: domain of guoxuenan@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=guoxuenan@huawei.com X-Rspam-User: X-HE-Tag: 1650799036-250476 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: Hi Matthew, You have done a lot of work on folio, many folio related patches have been incorporated into the mainline. I'm very interested in your excellent work and did some sequential read test (using fixed read length, testing on a 10G file), and found something. 1. different read length may effect folio order using 100KB read length during sequentital read, when readahead folio order may always 0, so there always allocate folios with 0 or 2. 2. folio order can not reach MAX_PAGECACHE_ORDER, when read length is small. (eg, less than 32KB) As you have mentationed here[1], "The heuristic for choosing which folio sizes will surely need some tuning" I wonder (1) why the folio order need align with page index. is this necessary or there are some certain restrictions? (2) for pagecache, by using large folio, it saving loops for allocating pages, and i also did some test on dropcache, it shows that dropcache costs less time. there are twenty times performance improvement when drop the 10G file's cache. so, can i concluded that pagecache should tend to use large order of folio? [1] https://lore.kernel.org/linux-mm/20220204195852.1751729-72-willy@infradead.org/, Thanks, Guo Xuenan