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 5F78DC433EF for ; Wed, 5 Jan 2022 10:54:33 +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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Q4ggXmBm9YgmGcH/bPyY6iNZu/vX+5F+T0Z0c5Rqv9A=; b=QqoFMR/ozpGedd w5s9UJAjFNnYDRePnmCZiughBehVUYx70G6Ku1YUZj5qxMDPKgUSD+JF59h6kQrOl15LHuv+jbJVN 0ekpQiJ2EZ20Ym9RHkll4gZoSWm4FGaV9EYpr4ufkmB1hdDdrjYOkYEcha/TnMsTjIRmSmepx45UQ awHwIpP5Gqr6X8Cyd5fGiCpxw6ffwPdi04Y0GBaiKSCJ2PyFeTN/5gwPouofspOO+fxebG4YBXUbM KaXWZYGUi5zqkT9Yx/UCmQvCWyxPIQDvgJskuPyvMQbQXmEEOlyeI4YQ/L284BoUfleM36qxg5rjA 6ACzfUkVVa08N7yNRbdA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n53uy-00Eb06-Ow; Wed, 05 Jan 2022 10:53:20 +0000 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n53uu-00Eayg-JK for linux-arm-kernel@lists.infradead.org; Wed, 05 Jan 2022 10:53:18 +0000 Received: by mail-io1-xd31.google.com with SMTP id x6so47622088iol.13 for ; Wed, 05 Jan 2022 02:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=u91RUSIYT5p0XTVAkEJuiBed73+WwWLBIzad/kDfbek=; b=E4nEpcuzA0T/R6uxEioFi0RrB2az7KwqsGwFdMCjOZXcSUO1B6wruAm0MmbllUEzIb mAadOdJFnrBnnz+0N9HwUakmLRlhq96+51MdFDPf1n7fHMPWEt+4PGZ+zwZ2OOD84eIK 7sdmkeao9NtFW7hfR4+ij7ori7FNJv3QsYKEvlUmabA52HzKGs+iMmA5rAMVkaUje1rR YBVte7h87V/qre6UqtrMX/jJxGrbuYGHJhC8hFG6cNb5HjfAKT3mqwzUzZbh7hWDZJ0b 9YHlA+R1X3uMV81Ni3PdMJvmm6bGD4+NynyM7urgZGiE/9c8DhIRX6aBIDLS6/dMg2UF iRzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=u91RUSIYT5p0XTVAkEJuiBed73+WwWLBIzad/kDfbek=; b=STaj8G4COxp8bD7LyLmJKzEUzp2zxyyCg9cNqL19wvY/jL23CABDXZv3XPQ65WERoh 7555UtKtwtI0vsYF9ct8bWhL+Tr1BJ/HUL5LCrL5bl2XKWD1bz6A89nvjOQK6QMmBZK2 n0IIkk2Vw+oNGI+yWHBBU2sqcexSx2vHF7B0uuFOteIhIZq7KMUtFtGJa7vZvxURCADH wV2MLuwB9+QNUMoFyibE4lTOrJmIDyGG2dsIahnxN/HPhLHJnm9+dg7PSh7Tyv7wBuHN yTeFsb3k3x5KrycodbH/r7oCvo/w8d4Vr43e1HfjQXGi2o4MnNY1do3A8pCxWYlEkqam jFNw== X-Gm-Message-State: AOAM530wN1w3xlmdUmccguUWb7dqIEkHTgKo6ubtTU5kQA6zuPdDN2Vd 0emjHKjRe52GUUSFnGBKNdY8Hw== X-Google-Smtp-Source: ABdhPJzs+sAfmI2Gp6IGVCopvN0kL6sh3lpkuMa1O7dzJPwnmBMMPnj+98RQ5sR5sKBemYkMpYjM9g== X-Received: by 2002:a05:6602:2a44:: with SMTP id k4mr25896072iov.43.1641379994997; Wed, 05 Jan 2022 02:53:14 -0800 (PST) Received: from google.com ([2620:15c:183:200:6c8c:5506:7ca2:9dfd]) by smtp.gmail.com with ESMTPSA id f14sm19073576ila.0.2022.01.05.02.53.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 02:53:14 -0800 (PST) Date: Wed, 5 Jan 2022 03:53:07 -0700 From: Yu Zhao To: SeongJae Park 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 Message-ID: References: <20220104202227.2903605-1-yuzhao@google.com> <20220105085534.22981-1-sj@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220105085534.22981-1-sj@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220105_025316_697080_BD4E9AB8 X-CRM114-Status: GOOD ( 24.96 ) 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: , 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 On Wed, Jan 05, 2022 at 08:55:34AM +0000, SeongJae Park wrote: > 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. Ok, I will sound harsh because I hate it when people challenge facts while having no idea what they are talking about. Our jobs are help the leadership make best decisions by providing them with facts, not feeding them crap. Don't get me wrong -- you are welcome to start another thread and have a casual discussion with me. But this thread is not for that; it's for the leadership and stakeholder to make a decision. Check who are in "To" and "Cc" and what my request is. > I didn't read this patchset thoroughly yet, so I might missing many things. If > so, please feel free to let me know. Yes, apparently you didn't read this patchset thoroughly, and you have missed all things that matter to this thread. > First, you can do thrashing prevention using DAMON-based Operation Scheme > (DAMOS)[1] with MADV_COLD action. Here is thrashing prevention really means, from patch 8: +Personal computers +------------------ +:Thrashing prevention: Write ``N`` to + ``/sys/kernel/mm/lru_gen/min_ttl_ms`` to prevent the working set of + ``N`` milliseconds from getting evicted. The OOM killer is invoked if + this working set can't be kept in memory. Based on the average human + detectable lag (~100ms), ``N=1000`` usually eliminates intolerable + lags due to thrashing. Larger values like ``N=3000`` make lags less + noticeable at the cost of more OOM kills. It's about when to trigger OOM kills. Got it? Or probably you don't understand what MADV_COLD is either? > Second, for working set estimation, you can either use the DAMOS > again with statistics action, or the damon_aggregated tracepoint[2]. This is you are suggesting: TRACE_EVENT(damon_aggregated, TP_printk("target_id=%lu nr_regions=%u %lu-%lu: %u", __entry->target_id, __entry->nr_regions, __entry->start, __entry->end, __entry->nr_accesses) Now read my doc again: +Data centers +------------ +:Debugfs interface: ``/sys/kernel/debug/lru_gen`` has the following + format: + memcg memcg_id memcg_path + node node_id Have you heard of something called memcg? And NUMA node? How exactly can this tracepoint provide information about different memcgs and NUMA node? > The DAMON user space tool[3] helps the tracepoint analysis and > visualization. What does "work out of box" mean? Should every Linux desktop, laptop and phone user install this tool? > Finally, for the proactive reclaim, you can again use the DAMOS > with MADV_PAGEOUT action How exactly does MADV_PAGEOUT find pages that are NOT mapped in page tables? Let me tell you another fact: they are usually the cheapest to reclaim. > or simply the DAMON-based proactive reclaim module (DAMON_RECLAIM)[4]. > [4] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html How many knob does DAMON_RECLAIM have? 14? I lost count. > Of course, the integration might not be so simple as seems to me now. Look, I'm open to your suggestion. I probably should have been nicer. So I'm sorry. I just don't appreciate alternative facts. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel