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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A26ABC433EF for ; Wed, 5 Jan 2022 08:57:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Message-Id:Date: Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=KsKLz+If8Qhtu7ml/Jifc68G5hLD7auAARYjsbRxmZo=; b=qvp4rDVwR9UHjm /Z/CjCj7DIplB4ZeMYTcT4sm6rL+qUMa6E87B/0cAGfJM03jjvWzX4llQxSBPYN0g9mDQnl2ARufK wdybK7ggKpWpuJ+Pap1l5T5D8P+EeboQR4xHm2a7n/s5xHUxkpo6vYuVLE7AAHirnUdpsZXpg3B/e u5WR4J7qKaOOq9snvXDWkI2RqlWYD2O7kpLFtsB5ktTr7T8UyzwBC29gmDgthJ9xcAZ6Te5FX8BXz T3dwHX6/qnCXUba6RgTOOb5vfUCd4AU0+X0X33DlnSjrfCpzP1xuvY+JdpBPQnSH1OOUswLCP5Fwj Ht6K+WEJdQK2+Vc+NvuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n525J-00EHF7-7p; Wed, 05 Jan 2022 08:55:53 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5258-00EHAh-H2 for linux-arm-kernel@lists.infradead.org; Wed, 05 Jan 2022 08:55:44 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 68372B8196E; Wed, 5 Jan 2022 08:55:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40542C36AED; Wed, 5 Jan 2022 08:55:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641372939; bh=8g2/BPq40vc0NB9YrpqVmK/MOPITFPSqe8IDisKitYM=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=RhlC90KRwV78uVdBiA0YhKQFavgF1UGclkv2HRA99uEzfv/1Ohf7wWXR1DCOmJwdX aZQayzLZ0i3HGIycHmFH7u6kK7dYQzmLliPYYH3l5Zf7Hr3N+gLloYw7M4+2zC4wNd pu3RUfIzIai7MzOFl7KdUgS/qvI730/nCYneNqMQkTSLZczGyT8yGXD0v4MYgyXBmQ FlMQeSqH+tPmJpqIjlOWkppbyF4Ejv3WaqwhlcyJcRpS1DVFiRsIk/DUX7COleX4Nl xuWw5stqjVgl5WOrX8JOPSLw4FgD2azP+z09MWNl1fdU7nFnRCzVhrqiblUxQPrSC1 Ahpc97PzKVbqw== From: SeongJae Park To: Yu Zhao Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, x86@kernel.org Subject: Re: [PATCH v6 0/9] Multigenerational LRU Framework Date: Wed, 5 Jan 2022 08:55:34 +0000 Message-Id: <20220105085534.22981-1-sj@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220104202227.2903605-1-yuzhao@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220105_005542_885636_651B338A X-CRM114-Status: GOOD ( 19.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Yu, On Tue, 4 Jan 2022 13:22:19 -0700 Yu Zhao wrote: > TLDR > ==== > The current page reclaim is too expensive in terms of CPU usage and it > often makes poor choices about what to evict. This patchset offers an > alternative solution that is performant, versatile and > straightforward. > [...] > Summery > ======= > The facts are: > 1. The independent lab results and the real-world applications > indicate substantial improvements; there are no known regressions. So impressive results! > 2. Thrashing prevention, working set estimation and proactive reclaim > work out of the box; there are no equivalent solutions. I think similar works are already available out of the box with the latest mainline tree, though it might be suboptimal in some cases. First, you can do thrashing prevention using DAMON-based Operation Scheme (DAMOS)[1] with MADV_COLD action. Second, for working set estimation, you can either use the DAMOS again with statistics action, or the damon_aggregated tracepoint[2]. The DAMON user space tool[3] helps the tracepoint analysis and visualization. Finally, for the proactive reclaim, you can again use the DAMOS with MADV_PAGEOUT action, or simply the DAMON-based proactive reclaim module (DAMON_RECLAIM)[4]. Nevertheless, as noted above, current DAMON based solutions might be suboptimal for some cases. First of all, DAMON currently doesn't provide page granularity monitoring. Though its monitoring results were useful for our users' production usages, there could be different requirements and situations. Secondly, the DAMON-based thrashing prevention wouldn't reduce the CPU usage of the reclamation logic's access scanning. So, to me, MGLRU patchset looks providing something that DAMON doesn't provide, but also something that DAMON is already providing. Specifically, the efficient page granularity access scanning is what DAMON doesn't provide for now. However, the utilization of the access information for LRU list manipulation (thrashing prevention) and proactive reclamation is similar to what DAMON (specifically, DAMOS) provides. Also, this patchset is reducing the reclamation logic's CPU usage using the efficient page granularity access scanning. IMHO, we might be able to reduce the duplicates by integrating MGLRU in DAMON. What I'm saying is, we could 1) introduce the efficient page granularity access scanning, 2) reduce the reclamation logic's CPU usage by making it to use the efficient page granularity access scanning, and 3) extend DAMON for page granularity monitoring with the efficient access sacanning[5]. Then, users could get the benefit of MGLRU by using DAMOS but setting it to use your efficient page granularity access scanning. To make it more simple, we can extend existing kernel logics to use DAMON in the way, or implement a new kernel module. Additional advantages of this approach would be 1) reducing the changes to the existing code, and 2) making the efficient page granularity access information be utilized for more general cases. Of course, the integration might not be so simple as seems to me now. We could put DAMON and MGLRU together as those are for now, and let users select what they really want. I think it's up to you. I didn't read this patchset thoroughly yet, so I might missing many things. If so, please feel free to let me know. [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes [2] https://docs.kernel.org/admin-guide/mm/damon/usage.html#tracepoint-for-monitoring-results [3] https://github.com/awslabs/damo [4] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html [5] https://docs.kernel.org/vm/damon/design.html#configurable-layers Thanks, SJ [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel