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 66C82CEFC41 for ; Tue, 8 Oct 2024 18:50:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA5E96B008A; Tue, 8 Oct 2024 14:50:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D55856B0093; Tue, 8 Oct 2024 14:50:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1D146B0096; Tue, 8 Oct 2024 14:50:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9D1F96B008A for ; Tue, 8 Oct 2024 14:50:27 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E5955140A6B for ; Tue, 8 Oct 2024 18:50:25 +0000 (UTC) X-FDA: 82651325694.13.5581CC5 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf16.hostedemail.com (Postfix) with ESMTP id 7D54B180009 for ; Tue, 8 Oct 2024 18:50:25 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s2H4t8Ws; spf=pass (imf16.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728413356; a=rsa-sha256; cv=none; b=uQVN+VIBvjJTPgpSvEdVnCH4+AUt2DxIBAJQOHa78k6KHh5RAo3TRXsahdX4rsgY45d9fz hoJT9Qq/UiVROPoh6BBW90G1SZltmGxG3UQjy9CdjlJOqTBhTV3PS/yL8l7p8KMtzoJVjW hqd1aKy6NEJl1Foyi7rqNjXlraZWZWI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s2H4t8Ws; spf=pass (imf16.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728413356; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vW2DFVL23cEA6S1+5xbu8zquXJpFHgF+O407S7qzmhE=; b=zmPNk05uqVF1d7uL13fpARS+uc8XPWNPspOfCeb1675uPpAej/9onOCxX+jygEzLCpzOZ4 MTFxeNjEtTnT2iaHhEoKkMK+HEQGRYFJWi33e57AA3Dwal2CO8H6DU2kANKdJajmNxxW6v 8knUa4cnYEtE7ZzlMZKda1z3PdtEGvw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1525AA4322A; Tue, 8 Oct 2024 18:50:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3197BC4CEC7; Tue, 8 Oct 2024 18:50:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728413424; bh=gmAb+I6DxEmcVFUgNnJntjcsNFS1xsuY5rkREQcTV9w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s2H4t8WselWPmUi2Y5mIg/+RKVYiMf9vi/K5C4gUQRiAt8xxMKHCd+sA5mBNWx4+n Y6K2HEFCM/fUVxE430XwgDHoyES3+wWo4gvoKgSj8l5vGeamIGGtoJXifIKicfbm2x 9iOH+Smavusn+errpvP74k+fW/AILFa/WW5t/uuZoCMlVLkx7k6CgfJ+vLtsXiqMVn vYW412VVfQ2tRIA92O1m1WlTVTZekUzaea+mrl+kIh3sY3p3z0Em2tniINi/OnHovn +N29ASV4W/bd68WjGJ7NAngKigJRNLxgurZEsbfXa25BE59ZAAaUFkkit6dm5Da6uD xRjRftKS7sGpg== From: SeongJae Park To: Minwoo Jo Cc: SeongJae Park , akpm@linux-foundation.org, rostedt@goodmis.org, mhiramat@kernel.org, willy@infradead.org, linux-mm@kvack.org Subject: Re: [PATCH] Hitshield : Something new eviction process for MGLRU Date: Tue, 8 Oct 2024 11:50:13 -0700 Message-Id: <20241008185013.64990-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20240802000546.322036-1-chminoo@g.cbnu.ac.kr> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: 836aej6h5ji6r1e3ipx7cfee4bwd8fkq X-Rspamd-Queue-Id: 7D54B180009 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728413425-213641 X-HE-Meta: U2FsdGVkX1/h5+uyUhNoqty45NgDGE5veQL6xdw1OWAdNmgvTB+x/DcQtlXFLWHwBm41MIF59G58W05EcU5MlGexR6Xcb3fLKfwbYa4GC9KDMfe3LpQgO0H3nK1IGdeYFzIUvxjlRoYQhqswohoUAwC7p70Gj1haEzGHM/c9gT5ZomBXjs2Q9RESMQg9Vzfq/MirQ0BBzn+Sfv2XssFIICqqNPnzQuIOZbCafglvZfYveiAfGVPMhUTdEhCjLzOKuB1mYmLFlwTUFiIg/bfhtl0zoDynSkdNXNCgO9PSf3qter1CZHgPZWtWQrZbNxpxM1TruIJpTOHA7qbUHjLnCjl7zP4oWyo/KI4U1Nk4wak6lVVTARKVuESyEFaGvnE5RwXyJKkY/qQa5CdEUzZgsLqH0+PpfaxOXf5e0NAfrrmXDeON3TjPErjG/Ix6yQapUITDGvtKXJJegxhZ8Kd7aUqrA6dUSftSpsfrhjMPPaGPBFAfR3nIzDjblLXojw1AYsGGdgV4EBH5BF0gPsBJbp2RnEfyS8o6TkUDzsDP1aR4Rx7v3zSRLCG3ISSbZWq+vBVUuTYzqNXnMfyCZX411iDj+jQJOlJIUV88iCY+K6P61IZwAUd+URjSlKbAQ7eLVWTHlk75mTC9aVbfLYq47ZM5AEmnqHIbVdfUFUyBM4HH5m/w0Tmt5b8yCmh26guzjv8B25baLOjvhiSEwoc/ZXAPJxzGR0Fl+lA90tIEinjJwZihB9cofE5cw6r7G6f0SdaGvDVDyptp6bykGXznGpFt8C0thR0ucn4JP0bn9ROcD58vrJagnGchMURjfzTRIXo9PSv/7UlBiPzMuxKhKliHVOd75yWQ8wNWTV+R+SN5oIaA4b09XKq9dkXpv9jZYqEjYLLbYVH1HJmczDxHUPbs4Bu3++8bNEEJU9tHtrikKbd/2jbaxBrSkLyBSVEDiyk34jrD+pexnOWDsK4 wRekzH9y 5d50fFJZLMWMbVCckyOGQ+7uSFQ76n4DV63BS5GR/lIqO1c5NsTmZqcHEkkqye8ae/k7Z2woVUSpjbax24UCsVvpvGaoA7QCyGMXKSHx8Y9zSjMotwDTX9hSbfdXLXHbsyMnXsmAWn5rhq4iCYQ5yrHnFh1o6BPmjODhzf85ZOALNEuQVHc/e1MirSYNisLHzZv2BlH9zFV+Vd9PrMJtq0+TGm1pKFcj4ydk4l4AGkYapBYpZCKxS2sTPrKTe075bFCJmtAqenUMAPzTYU2vDXXpXaXGybu9noVpl5wtbhov2xIptqRXc5q/Zip64TC8k/YTPtiElkgnOshcU+bjt25FZ0g== 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: Hello Minwoo, On Fri, 2 Aug 2024 00:05:46 +0000 Minwoo Jo wrote: > Signed-off-by: Minwoo Jo > > This commit addresses the page space occupancy issue that arose > in the previous commit with the HitShield technology. > > The HitShield technology is based on the observation that MGLRU > does not take into account the state of the folio during eviction. > > I assumed that if a folio, which has been updated only 1 to 3 times, > has increased in generation until the point of eviction, > it is likely to be referenced less in the future. So, my humble understanding of the point is that, you want to improve the kernel's reclamation logic by making it awares not only recency, but also frequency? Given existence of several previous frequency based page placement algorithm optimization researches including LRFU, CAR and CART, I think the overall idea might make sense at least in some use cases. I'm not sure whether the threshold value and the mechanism to measure the frequency make sense and/or can be applied to general cases, though. > > Therefore, I implemented this technology to protect frequently updated folios. > > I added the hitshield_0, hitshield_1, and hitshield flags to the page flag. > > Upon my review, I confirmed that the flags occupy positions 0 to 28. > > Thus, I believe that allocating 3 flags, or 3 bits, is sufficient. As others also mentioned, I think even three bits could be challinging to add. In my humble opinion, frequency monitoring could be done using data structures and access check mechanisms other than folio/LRU and reclamation logic. Then, the monitoring mechanism could manipulate LRU lists based on the frequency data. Modifying reclamation code to refer to the frequency data could also be another way. DAMON_LRU_SORT [1,2] could be an example of such approaches (driven by the monitoring mechanism without reclamation code modification). Of course, DAMON_LRU_SORT would have many limitations and rooms for improvements. I'm curious if you also had a time to consider that kind of approaches? If you did so but found some critical problems and resulted in this patch, it would be great if you can further share the found problems. [1] https://lwn.net/Articles/905370/ [2] https://www.kernel.org/doc/html/latest/admin-guide/mm/damon/lru_sort.html Thanks, SJ [...]