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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECBE0C47084 for ; Tue, 25 May 2021 15:44:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 911F2613E6 for ; Tue, 25 May 2021 15:44:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 911F2613E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6919B6B0036; Tue, 25 May 2021 11:44:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62F046B006E; Tue, 25 May 2021 11:44:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 433CF6B0070; Tue, 25 May 2021 11:44:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0124.hostedemail.com [216.40.44.124]) by kanga.kvack.org (Postfix) with ESMTP id 103006B0036 for ; Tue, 25 May 2021 11:44:36 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9EB9D180AD830 for ; Tue, 25 May 2021 15:44:35 +0000 (UTC) X-FDA: 78180175710.19.A7598C0 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf07.hostedemail.com (Postfix) with ESMTP id B2CD0A0001D6 for ; Tue, 25 May 2021 15:44:28 +0000 (UTC) Received: by mail-qt1-f178.google.com with SMTP id 1so23447014qtb.0 for ; Tue, 25 May 2021 08:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to; bh=qMaa25UCc9CiAt6aoLWjY2qUV9/trgZVm8dlt7Joxcs=; b=Vw1xB5ELFM2diO6zMjddIXMEed/HiuoUZn1OjBlHBnEn7ydLSPlltrbtw/6GX8tDA5 trv5bjLtr7DgGPYw2PdCv9sgvrOFlgIQzl2FIfBowGQgZMXNy0eKy112hdUgpaM4gkLs HMy3mx2xDQlZTBEil+4xElV/8EJpQiCmkf5CAB085XA/ucRYKy1WjMmwuvM4uaumO86p SlV76onPBllmRgOqs+f/EAByxbgDezJ7YiIYLESbqcONZ8BYHcPLubpdbuQIUFi2HUMJ dqIeQiG3rnQ5qbNGeayaSTxfcUWOJhaX71qcCjyp+nlnX+WoqErDfAsG2xgFDlVKh3vM CDuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to; bh=qMaa25UCc9CiAt6aoLWjY2qUV9/trgZVm8dlt7Joxcs=; b=fOQa4FefFBuWDpK2TUBwrspjcuq/Bqpy/xkJC0HK1Wmnm59sLyi/+AXkwilJIv70G2 JOxVGe2zMvE/uiEjWfpvE97LI1EeI4TLnLE1zvKHMHWoU9+bNjukS8XY2zQzwzqUc1Ns R/GLD4/RFVmOP9rwoyw65ck09NK8TjLz4XkX0BAKko5r7+Njj29S75QI9ZF6yNJrGBxZ jYul2XncX+1ULljYHssnAX41jRawRMAb8VCpXSpS6pduk37AO06nz6fkVqXwRmeMNktY tSu9eERPu4Gn79z+2nzj57wksufHAPNS5x2rWYPcwar+pcoLavc7auxW1CygrGIuHOei K7hw== X-Gm-Message-State: AOAM532K2i12huMPXelI93qE2VP+CVG/Vxz5KomuPQU2FcCFBL4qpdxG s8Ir3xwFMGZQjMBKXJvDCuY= X-Google-Smtp-Source: ABdhPJxSqkNVKiWX/7LV1mw4xRiYgCQpUWuLY3Eg/um5IywI0cE12Onm7KksFYqE3PmTtU/b3pKuRA== X-Received: by 2002:ac8:4756:: with SMTP id k22mr33228895qtp.193.1621957474640; Tue, 25 May 2021 08:44:34 -0700 (PDT) Received: from localhost.localdomain (ec2-35-169-212-159.compute-1.amazonaws.com. [35.169.212.159]) by smtp.gmail.com with ESMTPSA id e4sm3124255qtq.5.2021.05.25.08.44.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 May 2021 08:44:33 -0700 (PDT) From: SeongJae Park X-Google-Original-From: SeongJae Park To: sieberf@amazon.com Cc: sj38.park@gmail.com, Jonathan.Cameron@Huawei.com, acme@kernel.org, akpm@linux-foundation.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendanhiggins@google.com, corbet@lwn.net, david@redhat.com, dwmw@amazon.com, elver@google.com, fan.du@intel.com, foersleo@amazon.de, greg@kroah.com, gthelen@google.com, guoju.fgj@alibaba-inc.com, linux-damon@amazon.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de, minchan@kernel.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, riel@surriel.com, rientjes@google.com, rostedt@goodmis.org, rppt@kernel.org, shakeelb@google.com, shuah@kernel.org, sjpark@amazon.de, snu@amazon.de, vbabka@suse.cz, vdavydov.dev@gmail.com, zgf574564920@gmail.com Subject: Re: [PATCH v29 05/13] mm/damon: Implement primitives for the virtual memory address spaces Date: Tue, 25 May 2021 15:44:27 +0000 Message-Id: <20210525154427.30921-1-sjpark@amazon.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <3da2bb79-4448-4857-a9d1-698a360c51a2@amazon.com> Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Vw1xB5EL; spf=pass (imf07.hostedemail.com: domain of sj38park@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=sj38park@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B2CD0A0001D6 X-Stat-Signature: dhtn1dsws9t6z4f7wbw154xciatenfak X-HE-Tag: 1621957468-630832 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: From: SeongJae Park On Tue, 25 May 2021 17:19:04 +0200 wrote: > Hi SeongJae, > > Some questions for this patch: > > Why do we split the regions in 3 areas (heap, stack, mmaped)? I > understand we don't want to model the whole virtual address space, but > why don't we just use whatever is modeled by the VMAs to define the > regions boundaries? First of all, number of VMAs could be very large in some processes. Also, VMAs could have small gaps between them so that our merge/split strategy doesn't works effectively. > > I am not quite understanding why we both set the page idle and young (in > damon_ptep_mkold). For WSS computation on our end we have used > pte_clear_young_notify. Why do we touch the page idle flag at all? What > flags do the reclaim logic use to track access? Both DAMON and reclaim logic read and write 'Accessed' bits in page table entries to check if a page is accessed or not. Because this could let them interfere each other, we have two per-page flags called PG_Idle and PG_Young, which save the original state of the 'Accessed' bit. For example, if DAMON needs to clear 'Accessed' bit of a page, it first sees if the page accessed. Because simply clearing the bit could make the reclaim logic thinks the page was not accessed, it sets PG_Young in this case. Later, when reclaim logic needs to check if the page is accessed or not, it first reads the 'Accessed' bit, which cleared by DAMON, and finds it's not set. But, reclaim logic checks PG_Young together, which set by DAMON, so it knows the page has accessed. This also means PG_Young should cleared by reclaim logic, when it clears 'Accessed' bit. Similarly, DAMON sets PG_Idle when it clears 'Accessed' bit. And, vice versa for reclaim logic. Hope these answer your questions. If something unclear or I missed some of your point, please feel free to let me know. Thanks, SeongJae Park > > Kind regards, > > Fernand