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 06B92C3DA7F for ; Mon, 5 Aug 2024 11:29:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4595A6B0093; Mon, 5 Aug 2024 07:29:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E1D26B0095; Mon, 5 Aug 2024 07:29:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25BAE6B0096; Mon, 5 Aug 2024 07:29:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 04BF56B0093 for ; Mon, 5 Aug 2024 07:29:14 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 944CCC025E for ; Mon, 5 Aug 2024 11:29:14 +0000 (UTC) X-FDA: 82417970628.24.A7A045B Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf02.hostedemail.com (Postfix) with ESMTP id 3A05B8001F for ; Mon, 5 Aug 2024 11:29:11 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tGEd1noX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="Fi/SLQtn"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tGEd1noX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="Fi/SLQtn"; dmarc=none; spf=pass (imf02.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722857302; a=rsa-sha256; cv=none; b=Wgygc3PnmNUwIsRsj3AIdBDVozVBOwi3M3Dw9ql2JDo1YeRoBdHCh1l4IBKeolM9f5zyJ9 U3bsAdeyHcxuBZV8Iu4r2HOVUVMULiEtDFlyCk2LS+KukyzkNStW7zpDsNl8BjMfXmc0bo 8Se8PZwinIaXc3CXY1utpdy3K1tBRTc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tGEd1noX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="Fi/SLQtn"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=tGEd1noX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="Fi/SLQtn"; dmarc=none; spf=pass (imf02.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722857302; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=boKBY/XfyqO8lBDspt+WKzQHM1J1U6GyJ50MmpbVGJU=; b=NkWatmDssjj3u4Z5SHyWt2jT+hXTlKGkFO8nA65lHI+wpSvPLS44K0gM0xK+0/H8093xKP zPI5wULRhoijgbZjurdwOHRVnPAa/Fxcl+t7tWxVOxKrMBasvUFAZ3qVpEn5wf0SR//0M6 DQwoeOAkdHPXdhGOHI1eZz6D5eXFjsI= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 612401FD11; Mon, 5 Aug 2024 11:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1722857350; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=boKBY/XfyqO8lBDspt+WKzQHM1J1U6GyJ50MmpbVGJU=; b=tGEd1noXUuRiiUDkNwEua67579efpYvH7jf08fm1AurW2kzIDE3MhSbJBmkUZdaoWG9mYO GDV/swf7CBH9/cnwWwTQ+IFqytXEpOI0CwjwcCFKE3WabNeserAf/yE6zeoEbp+b7gGr6J TP8GPMbwBdbvH2B13lufgZjlM8BKvMY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1722857350; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=boKBY/XfyqO8lBDspt+WKzQHM1J1U6GyJ50MmpbVGJU=; b=Fi/SLQtnl0AedMfEJZLIUyLtZHM4tIGHvkyqEinhsFuxureqlYWTTP+4b23MFr9O7Sc5qY 1TMIAZl/OfHVjxAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1722857350; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=boKBY/XfyqO8lBDspt+WKzQHM1J1U6GyJ50MmpbVGJU=; b=tGEd1noXUuRiiUDkNwEua67579efpYvH7jf08fm1AurW2kzIDE3MhSbJBmkUZdaoWG9mYO GDV/swf7CBH9/cnwWwTQ+IFqytXEpOI0CwjwcCFKE3WabNeserAf/yE6zeoEbp+b7gGr6J TP8GPMbwBdbvH2B13lufgZjlM8BKvMY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1722857350; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=boKBY/XfyqO8lBDspt+WKzQHM1J1U6GyJ50MmpbVGJU=; b=Fi/SLQtnl0AedMfEJZLIUyLtZHM4tIGHvkyqEinhsFuxureqlYWTTP+4b23MFr9O7Sc5qY 1TMIAZl/OfHVjxAQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 4E09313ACF; Mon, 5 Aug 2024 11:29:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id KiWoEoa3sGZNFAAAD6G6ig (envelope-from ); Mon, 05 Aug 2024 11:29:10 +0000 Message-ID: <5e5e9b20-2998-46b3-8cd0-670365c035f1@suse.cz> Date: Mon, 5 Aug 2024 13:29:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Hitshield : Something new eviction process for MGLRU Content-Language: en-US To: Minwoo Jo , akpm@linux-foundation.org Cc: rostedt@goodmis.org, mhiramat@kernel.org, willy@infradead.org, linux-mm@kvack.org, Yu Zhao References: <20240802000546.322036-1-chminoo@g.cbnu.ac.kr> From: Vlastimil Babka In-Reply-To: <20240802000546.322036-1-chminoo@g.cbnu.ac.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3A05B8001F X-Stat-Signature: zpmws4czh6dmic6sajz8i9q7fk6o4mg8 X-Rspam-User: X-HE-Tag: 1722857351-608015 X-HE-Meta: U2FsdGVkX19L8F2CRPrF3yL6nv+MEOZi9qoO+JL/29OUsW60kHHnhk03MRfgOWDZr7H3JFNgD8PYR7f53fP7l6QD0UVPATO6tKFYZLx4rk7AXPssh1+skFe5sIblJFa+EyLWTXk306cLtpgfwJ1b4M3lcxWCAsDAxvkpNiqglh0CO1k/Vdu0Kk7YhMiwQBWeMZOdEVyDCfLMRySHqtCP6rnmgH2iEgN0pwO4Dpoqu4+EfdmfRnlYw2lgbonaCYrdJGcFuJ9KTZfnb36ZOFfLRnW0ph5lufhChzSg60y5ibKnCxUUCkJIjRn1UaWdKhxzbbC7gdAr5/jeaj7OzHBmo0JdMrIyX+HMCJIs8WpWRru9hL2sYOEQ7aIlVubk44PHhI8I/QZNd2z5Udb+j4gt7Gw/gO5KE/AMcgN8bBnQm2GrMjcKngEWMmYso7L5N31hlnpXzXRg+/+Oq1B+cjx8qGWmzuF7zs6w89PVVMNgbxm9/o3QR0gXEEd5CtCLvmFQOURLmW3GJmlKNQSFNpr9afD/s4vDndoC/9HmUxkB+ZVILDcSoBvar6/HCyGv2dcPAP0YfWMsEQT932cFYA0Bzgg2+KtXHlpg0b5VpUddEZGnZM8TR9S9ssVVBPgUdzi7w0OXFaiu4CHapxo7xiSW9lq9NipNKY2v6YUK7Cil9as/v9MKCqM581Bm+cimeeWG9hijFd70UX9WfNe7OA4IYoiIsArp9m/G9byrKwZ/C91JkEr3VOCxG/pmGdrQ0XYKzGF1LNaoLpZQf9IB6yjSQrGiZXptxr1E1cSp6Ks7p8ATCGIBXRSZoPiVfL1AO3Zo+Yg3QlpQtok5btPVeKPCEEkq8u1duT24p+taObQsqJiCWIIT4MbjOXi/PwOhi4rhnBSc63JxBI0AD09LdVph5Qx5zFmgD/gdRIiQgQAfdh4m1LCUsxUXhXHOc/OGRdzEGTg0rieSkS9mtEvvJOk FHuXIXHL Ci+npEzTAJX9cPnXQuFXrGM52vu4yrQAGpEnDrottKeIQISpCT/rFISt/5Q1YaOEmA3h87qnQYS2CA3lPMofHIHoSP8FCCqEpmNArKhm6qTGmYC748xwgabHwOy8o+ExNJYb4vHG0umC5/Ilfaa3Ajh5eJIb+5XK7NtiaUldG6ry1OqZmt2cAPrhbm0Sj/RfvNdDRpSWSjBdpEJFY9NJNFQfzZA2uPnWJS4LsQpsBZhuZPYVbN8ESydaHPYVvrpixH1ugbxBcxB5WOUE= 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: +Cc Yu Zhao On 8/2/24 02:05, 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. > > 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. > > The hitshield_0 and hitshield_1 flags serve as count flags, representing the digit positions in binary. > > The hitshield flag is a boolean flag used to verify whether the HitShield is actually enabled. > > Each time a folio is added to lrugen, the hitshield_0 and hitshield_1 flags are cleared to reset them. > > Subsequently, in the folio_update_gen function, I added the following code: > > if (!folio_test_hitshield(folio)) > if (folio_test_change_hitshield_0(folio)) > if (folio_test_change_hitshield_1(folio)) > folio_set_hitshield(folio); > > This code counts the HitShield, and if it exceeds 5, it sets the hitshield flag. > > In the sort_folio function, which is executed for eviction, if the folio's hitshield flag is set, > it ages the folio to max_gen and resets the flag. > > The testing was conducted on Ubuntu 24.04 LTS (Kernel 6.8.0) > with an AMD Ryzen 9 5950X 16Core (32Threads) environment, restricting DRAM to 750MiB through Docker. > > In this environment, the ycsb benchmark was tested using the following command: > > ./bin/ycsb load mongodb -s -P workloads/workloadf -p recordcount=100000000 -p mongodb.batchsize=1024 > -threads 32 -p mongodb.url="mongodb://localhost:27017/ycsb" > > During testing, a reduction of 78.9% in pswpin and 75.6% in pswpout was measured. > > Additionally, the runtime for the Load command decreased by 18.3%, > and the runtime for the Run command decreased by 9.3%. > > However, when running a single-threaded program with the current implementation, > while a decrease in swap counts was observed, the runtime increased compared to the native MGLRU. > > A thorough analysis is needed to understand why this occurs, but I think it appears > that there is significant overhead from the flag calculations. > > Therefore, it seems that if we activate this functionality through an ifdef statement > only in certain situations, we could achieve performance benefits. > > As an undergraduate student who is still self-studying the kernel, I am not very familiar with using ifdef, > so I did not write that part separately. > > I apologize for not being able to test it with large memory swap workloads, > as I was unsure what would be appropriate. > > I would appreciate your review and feedback on this approach. > > Thank you. > --- > include/linux/mm_inline.h | 4 ++++ > include/linux/page-flags.h | 26 ++++++++++++++++++++++++++ > include/trace/events/mmflags.h | 5 ++++- > mm/vmscan.c | 22 ++++++++++++++++++++++ > 4 files changed, 56 insertions(+), 1 deletion(-) > > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h > index f4fe593c1400..dea613b2785c 100644 > --- a/include/linux/mm_inline.h > +++ b/include/linux/mm_inline.h > @@ -266,6 +266,10 @@ static inline bool lru_gen_add_folio(struct lruvec *lruvec, struct folio *folio, > else > list_add(&folio->lru, &lrugen->folios[gen][type][zone]); > > + folio_clear_hitshield_0(folio); > + folio_clear_hitshield_1(folio); > + /* This for initialize hit_shield by 0 when folio add to gen */ > + > return true; > } > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index 5769fe6e4950..70951c6fe4ce 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h > @@ -130,6 +130,16 @@ enum pageflags { > PG_arch_2, > PG_arch_3, > #endif > + PG_hitshield_0, > + PG_hitshield_1, > + PG_hitshield, > + > + /* > + * The flags consist of two types: one for counting the update occurrences > + * of the folio and another boolean flag to check whether the HitShield is activated. > + */ > + > + > __NR_PAGEFLAGS, > > PG_readahead = PG_reclaim, > @@ -504,6 +514,14 @@ static inline int TestClearPage##uname(struct page *page) { return 0; } > #define TESTSCFLAG_FALSE(uname, lname) \ > TESTSETFLAG_FALSE(uname, lname) TESTCLEARFLAG_FALSE(uname, lname) > > +#define TESTCHANGEPAGEFLAG(uname, lname, policy) \ > +static __always_inline \ > +bool folio_test_change_##lname(struct folio *folio) \ > +{ return test_and_change_bit(PG_##lname, folio_flags(folio, FOLIO_##policy)); } \ > +static __always_inline int TestChangePage##uname(struct page *page) \ > +{ return test_and_change_bit(PG_##lname, &policy(page, 0)->flags); } > +/* This macro function allows the use of the change operation defined in bitops. */ > + > __PAGEFLAG(Locked, locked, PF_NO_TAIL) > FOLIO_FLAG(waiters, FOLIO_HEAD_PAGE) > PAGEFLAG(Error, error, PF_NO_TAIL) TESTCLEARFLAG(Error, error, PF_NO_TAIL) > @@ -559,6 +577,14 @@ PAGEFLAG(Reclaim, reclaim, PF_NO_TAIL) > PAGEFLAG(Readahead, readahead, PF_NO_COMPOUND) > TESTCLEARFLAG(Readahead, readahead, PF_NO_COMPOUND) > > +/* > + * hitshield_0 and 1 use only clear and test_change functions, also > + * hitshield flag uses only set, test, test_clear function > + */ > +PAGEFLAG(Hitshield0, hitshield_0, PF_HEAD) TESTCHANGEPAGEFLAG(Hitshield0, hitshield_0, PF_HEAD) > +PAGEFLAG(Hitshield1, hitshield_1, PF_HEAD) TESTCHANGEPAGEFLAG(Hitshield1, hitshield_1, PF_HEAD) > +PAGEFLAG(Hitshield, hitshield, PF_HEAD) TESTSCFLAG(Hitshield, hitshield, PF_HEAD) > + > #ifdef CONFIG_HIGHMEM > /* > * Must use a macro here due to header dependency issues. page_zone() is not > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > index b63d211bd141..d7ef9c503876 100644 > --- a/include/trace/events/mmflags.h > +++ b/include/trace/events/mmflags.h > @@ -117,7 +117,10 @@ > DEF_PAGEFLAG_NAME(mappedtodisk), \ > DEF_PAGEFLAG_NAME(reclaim), \ > DEF_PAGEFLAG_NAME(swapbacked), \ > - DEF_PAGEFLAG_NAME(unevictable) \ > + DEF_PAGEFLAG_NAME(unevictable), \ > + DEF_PAGEFLAG_NAME(hitshield_0), \ > + DEF_PAGEFLAG_NAME(hitshield_1), \ > + DEF_PAGEFLAG_NAME(hitshield) \ > IF_HAVE_PG_MLOCK(mlocked) \ > IF_HAVE_PG_UNCACHED(uncached) \ > IF_HAVE_PG_HWPOISON(hwpoison) \ > diff --git a/mm/vmscan.c b/mm/vmscan.c > index cfa839284b92..b44371dddb33 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3148,6 +3148,18 @@ static int folio_update_gen(struct folio *folio, int gen) > new_flags |= (gen + 1UL) << LRU_GEN_PGOFF; > } while (!try_cmpxchg(&folio->flags, &old_flags, new_flags)); > > + /* > + * This part is core of hit_shield : Has this folio been updated frequently? > + * I chose 5 as the number of times to grant shield because of MAX_NR_GENS is 4, > + * so if this folio has been updated for more than a generation's length, > + * it has additional survivability equal to the generation's length. > + */ > + > + if (!folio_test_hitshield(folio)) > + if (folio_test_change_hitshield_0(folio)) > + if (folio_test_change_hitshield_1(folio)) > + folio_set_hitshield(folio); > + > return ((old_flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF) - 1; > } > > @@ -4334,6 +4346,16 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c > return true; > } > > + /* this when hit_shield is enabled > + * init hit_shield again, and protect this folio like second chance algorithm > + */ > + > + if (folio_test_clear_hitshield(folio)) { > + gen = folio_inc_gen(lruvec, folio, true); > + list_move(&folio->lru, &lrugen->folios[gen][type][zone]); > + return true; > + } > + > return false; > } >