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 EF92CC433EF for ; Tue, 22 Feb 2022 01:49:09 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Zfx6syBl5R5EURZBxKym0oBiDqUyhqASJ2M4T0o7t38=; b=kfGDryzR++Fo0Z IWqrOVI3uVjFNU/Phtpp+5Ut0tg6rYiYgCPykxF20knT7sC4F/nOShwccMTuYy/YC2EF79+/eSoid 05z7qiFhJcWOC6ADaqH3Uk1eGBvxV3f9BFd/XMDAPg08yY1KDmw1kCBhZBGKsWFt4v/TCJj4WNSQh mBplAP7tCHsaea/ZyBKcuIZPyN/NoJ1cSGTzlSymUOMYk1yVDrb2+4lrtBvef18p4/+aOCpH2sGPy 1xeA7ot0QjC9b645Tig4s0hDuL88G3Zyn4Glod4CUDLBGtGZOzC0n+ohETs2mkY8MIILedJZrGviD CiY3eSoqXFvXqYhIwTMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMKHH-007fBq-A8; Tue, 22 Feb 2022 01:47:43 +0000 Received: from mail-vs1-xe33.google.com ([2607:f8b0:4864:20::e33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMKHD-007fAv-KU for linux-arm-kernel@lists.infradead.org; Tue, 22 Feb 2022 01:47:41 +0000 Received: by mail-vs1-xe33.google.com with SMTP id j3so5277545vsi.7 for ; Mon, 21 Feb 2022 17:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H78t/Tkekmq9O5Lj2Ksbs71PIv/v6BIhtnLX5Mxv/tc=; b=QfMTvyiwE3XGQ1znQQVazyaY8j7LOpDoxLgXasjsywlb12Uci3qRU1ZjDbs/DQksHh S9CjewhdqGO4rBR3DYFpHJcESh4eo60117lCdcr36OiDBNjU6VAgpoLLew5RWRXHW9GB m1xsEPuqNMhFg/usmYK3pEEmFu9C3uVvmOjv1vuoX+SQZ1x6SKN5SBuMLyNivWDp3jrS ZgylfMVMs2xuobHRidTGV30OXRrlh7FaEFFhHEru2MHPtldU4IyTMjUOT8xR9l/KEoS3 wUQpOR2AdJSZOVPBgowDlFMTQp0NlTPFJVNAR3nGjoMQTRPjOnvnq8zyBULD6N4nvUNd jdgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H78t/Tkekmq9O5Lj2Ksbs71PIv/v6BIhtnLX5Mxv/tc=; b=0TMeOu7M9+alQy6pkal/OWY5qsVcpK+98S+oWL++i5Fqx598eO2tZjT0NJVxWGVRV5 NqRs/HpxjVu3GxR9ZGm9IBkLyIxlREIb57Xe6SnW5tBX6/kojPBBa5JIrW3xx5jgzJ7r jD0tFkEE6IfluZV1ToWE0ehUkgv7z5Of5ne72oF1f7tyrM5Aa4Dmts+o0K7njFESR9Ef +Q/msvDZ98LvFT+YXKwCxBOqQk7a9Db58poee0mwke9fwxcRQ1G8A/bW5rn/hZD/DHJa LChk30EPuDZ9Hwbu/oGjJRRreuQ+M4Q94X25TXlq3t6J55EUEXVlIMqz28yXm8Dq24tA SvIw== X-Gm-Message-State: AOAM531OeKLwPU5u7C4HamHpZYUo9OvGxjhYyQADOeuldgHrw7+/87Eq k95Dz2Xoj/E+pbPsaL1WyNK69KXyegYvjFQ0zluF5A== X-Google-Smtp-Source: ABdhPJxIeyI3mYLfbDebz5kcexdOouEp1H1k6oTsKi5Lq57wRN56u1mCxv31zG/zmUgj5o8K0uV3wWd30Qc6oH/iWc4= X-Received: by 2002:a67:edce:0:b0:31c:405:cb78 with SMTP id e14-20020a67edce000000b0031c0405cb78mr6901843vsp.6.1645494456603; Mon, 21 Feb 2022 17:47:36 -0800 (PST) MIME-Version: 1.0 References: <20220208081902.3550911-1-yuzhao@google.com> <20220208081902.3550911-13-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Mon, 21 Feb 2022 18:47:25 -0700 Message-ID: Subject: Re: [PATCH v7 12/12] mm: multigenerational LRU: documentation To: Mike Rapoport Cc: Andrew Morton , Johannes Weiner , Mel Gorman , Michal Hocko , Andi Kleen , Aneesh Kumar , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Michael Larabel , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Linux-MM , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220221_174739_684322_3868858F X-CRM114-Status: GOOD ( 52.82 ) 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 Mon, Feb 21, 2022 at 2:02 AM Mike Rapoport wrote: > > On Tue, Feb 15, 2022 at 08:22:10PM -0700, Yu Zhao wrote: > > On Mon, Feb 14, 2022 at 12:28:56PM +0200, Mike Rapoport wrote: > > > > > > +====== ======== > > > > +Values Features > > > > +====== ======== > > > > +0x0001 the multigenerational LRU > > > > > > The multigenerational LRU what? > > > > Itself? This depends on the POV, and I'm trying to determine what would > > be the natural way to present it. > > > > MGLRU itself could be seen as an add-on atop the existing page reclaim > > or an alternative in parallel. The latter would be similar to sl[aou]b, > > and that's how I personally see it. > > > > But here I presented it more like the former because I feel this way is > > more natural to users because they are like switches on a single panel. > > Than I think it should be described as "enable multigenerational LRU" or > something like this. Will do. > > > What will happen if I write 0x2 to this file? > > > > Just like turning on a branch breaker while leaving the main breaker > > off in a circuit breaker box. This is how I see it, and I'm totally > > fine with changing it to whatever you'd recommend. > > That was my guess that when bit 0 is clear the rest do not matter :) > What's important, IMO, is that it is stated explicitly in the description. Will do. > > > Please consider splitting "enable" and "features" attributes. > > > > How about s/Features/Components/? > > I meant to use two attributes: > > /sys/kernel/mm/lru_gen/enable for the main breaker, and > /sys/kernel/mm/lru_gen/features (or components) for the branch breakers It's a bit superfluous for my taste. I generally consider multiple items to fall into the same category if they can be expressed by a type of array, and I usually pack an array into a single file. >From your last review, I gauged this would be too overloaded for your taste. So I'd be happy to make the change if you think two files look more intuitive from user's perspective. > > > > +0x0002 clear the accessed bit in leaf page table entries **in large > > > > + batches**, when MMU sets it (e.g., on x86) > > > > > > Is extra markup really needed here... > > > > > > > +0x0004 clear the accessed bit in non-leaf page table entries **as > > > > + well**, when MMU sets it (e.g., on x86) > > > > > > ... and here? > > > > Will do. > > > > > As for the descriptions, what is the user-visible effect of these features? > > > How different modes of clearing the access bit are reflected in, say, GUI > > > responsiveness, database TPS, or probability of OOM? > > > > These remain to be seen :) I just added these switches in v7, per Mel's > > request from the meeting we had. These were never tested in the field. > > I see :) > > It would be nice to have a description or/and examples of user-visible > effects when there will be some insight on what these features do. How does the following sound? Clearing the accessed bit in large batches can theoretically cause lock contention (mmap_lock), and if it happens the 0x0002 switch can disable this feature. In this case the multigenerational LRU suffers a minor performance degradation. Clearing the accessed bit in non-leaf page table entries was only verified on Intel and AMD, and if it causes problems on other x86 varieties the 0x0004 switch can disable this feature. In this case the multigenerational LRU suffers a negligible performance degradation. > > > > +:Debugfs interface: ``/sys/kernel/debug/lru_gen`` has the following > > > > > > Is debugfs interface relevant only for datacenters? > > > > For the moment, yes. > > And what will happen if somebody uses these interfaces outside > datacenters? As soon as there is a sysfs intefrace, somebody will surely > play with it. > > I think the job schedulers might be the most important user of that > interface, but the documentation should not presume it is the only user. Other ideas are more like brainstorming than concrete use cases, e.g., for desktop users, these interface can in theory speed up hibernation (suspend to disk); for VM users, they can again in theory support auto ballooning. These niches are really minor and less explored compared with the data center use cases which have been dominant. I was hoping we could focus on the essential and take one step at a time. Later on, if there is additional demand and resource, then we expand to cover more use cases. > > > > + job scheduler writes to this file at a certain time interval to > > > > + create new generations, and it ranks available servers based on the > > > > + sizes of their cold memory defined by this time interval. For > > > > + proactive reclaim, a job scheduler writes to this file before it > > > > + tries to land a new job, and if it fails to materialize the cold > > > > + memory without impacting the existing jobs, it retries on the next > > > > + server according to the ranking result. > > > > > > Is this knob only relevant for a job scheduler? Or it can be used in other > > > use-cases as well? > > > > There are other concrete use cases but I'm not ready to discuss them > > yet. > > Here as well, as soon as there is an interface it's not necessarily "job > scheduler" that will "write to this file", anybody can write to that file. > Please adjust the documentation to be more neutral regarding the use-cases. Will do. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel