Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp877921ybg; Tue, 28 Jul 2020 23:22:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNO2JRBdhznFTXn666r6gACMvK/5hw8xcWOmUKFpe4xvfjgGl0WvUucQcIP5Wb3kF2oqrZ X-Received: by 2002:a17:906:3009:: with SMTP id 9mr28323579ejz.220.1596003748675; Tue, 28 Jul 2020 23:22:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596003748; cv=none; d=google.com; s=arc-20160816; b=DQ8OjDomgu9aLP7BhJntGBLjBLERsMO00ODuRqH0qAX77NEYwwcZQErNz1x0cpnXdi HylQIrHG2cf1hg5Sb99vUSEsRm1rxGpGHgjd3D6MJExY7YAPpmtENI4N+NnwvLU9CLSB DwUp1wo74uVAWV9kI4l4E8ZYeZ9cLKcbu6pIpcYQpHquSvmdT7GzZbAayKQT48R7oDP4 apciEVCxmj8Ufse8xUHFfLdIfb3jI6xnCnrz3+W493yyX81NOfKjlu6SI/eQ3f/191hb I6ZJB6NakP82jN8Xb5ueuriVYFbubTFDo/mTcBa3nALb8fgmbZ3APTzbig9VZeIcKgmK SsKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:in-reply-to:message-id:date :subject:cc:to:from:ironport-sdr:dkim-signature; bh=EOsZrcI2DbHuHivAY32JN5S9Mkp+QickCr/976Dprho=; b=lLPnZK9RYhElzhbw0/rvXGRXOwHrXbtfo2myPxDBBC57hqveKPHmGPCsfLY9MTVAsS PW3LSggA9Urbd12Hl+Sl2J5m0K/1FzXs364Qx8QxwlYDjXuGF8vYbRj4X5SSyKIAhjtT SoGkWWhMYQBr4JgytCbS7XD94xbGi3XslEwvuOE/sOCISA6luIH9dVZdo2l4CqeHFirI 7FsPI5eqCu9IvAlFOEqqnabAUiwTCjnS78ive2q84FY2DTMKsePIQdXsZYiFL6cvA+B4 If1kyxHAUkULT3gxitWcDZcQL1HH//kNuiofjSbTnR+V48NIQ2/0HZ1teD0Vooevoe1l 4sBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.com header.s=amazon201209 header.b=uwtzVJYU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bi14si586133ejb.251.2020.07.28.23.22.06; Tue, 28 Jul 2020 23:22:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amazon.com header.s=amazon201209 header.b=uwtzVJYU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726718AbgG2GVz (ORCPT + 99 others); Wed, 29 Jul 2020 02:21:55 -0400 Received: from smtp-fw-9101.amazon.com ([207.171.184.25]:35007 "EHLO smtp-fw-9101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726290AbgG2GVz (ORCPT ); Wed, 29 Jul 2020 02:21:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1596003714; x=1627539714; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=EOsZrcI2DbHuHivAY32JN5S9Mkp+QickCr/976Dprho=; b=uwtzVJYUhLwpanfKHpobAUNJu51jf9DV+e7sRt3vjABvsFRn6FjznFg5 hqEGk9hjrsppBUJgoXmorctQlx2pCInf6C5lnNOvuH5uqWuBE0XKnZQHQ Bp03mWh425on+JUcPOQQiHTAmlN4pnY0dYWDSZBFuCU/qkzY/PZbRYC5U Q=; IronPort-SDR: RzgqiX2nL/gU1hoo7Kvw/A5K1c20F/a3+/46me7Xocorfd2CV+s37I2tRKN/2pTS5o73mF0yiq 2pPKRkKGtZvw== X-IronPort-AV: E=Sophos;i="5.75,409,1589241600"; d="scan'208";a="55653783" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 29 Jul 2020 06:21:49 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id EF2A5A23DE; Wed, 29 Jul 2020 06:21:38 +0000 (UTC) Received: from EX13D31EUA001.ant.amazon.com (10.43.165.15) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 06:21:37 +0000 Received: from u886c93fd17d25d.ant.amazon.com (10.43.162.221) by EX13D31EUA001.ant.amazon.com (10.43.165.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 06:21:08 +0000 From: SeongJae Park To: Shakeel Butt CC: SeongJae Park , Andrew Morton , SeongJae Park , , Andrea Arcangeli , , , , , , Brendan Higgins , Qian Cai , Colin Ian King , Jonathan Corbet , "David Hildenbrand" , , , Ian Rogers , , "Kirill A. Shutemov" , , Mel Gorman , Minchan Kim , Ingo Molnar , , "Peter Zijlstra (Intel)" , Randy Dunlap , Rik van Riel , David Rientjes , Steven Rostedt , , , , , , Vlastimil Babka , Vladimir Davydov , Yang Shi , Huang Ying , , Linux MM , , LKML Subject: Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces Date: Wed, 29 Jul 2020 08:20:42 +0200 Message-ID: <20200729062042.30136-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.43.162.221] X-ClientProxiedBy: EX13D19UWC001.ant.amazon.com (10.43.162.64) To EX13D31EUA001.ant.amazon.com (10.43.165.15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Jul 2020 10:42:11 -0700 Shakeel Butt wrote: > On Mon, Jul 27, 2020 at 2:03 AM SeongJae Park wrote: > > > > On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote: > > > > > SeongJae Park wrote: > > > > > > > From: SeongJae Park > > > > > > > > This commit introduces a reference implementation of the address space > > > > specific low level primitives for the virtual address space, so that > > > > users of DAMON can easily monitor the data accesses on virtual address > > > > spaces of specific processes by simply configuring the implementation to > > > > be used by DAMON. > > [...] > > > > diff --git a/mm/damon.c b/mm/damon.c > > > > index b844924b9fdb..386780739007 100644 > > > > --- a/mm/damon.c > > > > +++ b/mm/damon.c > > > > @@ -9,6 +9,9 @@ > > [...] > > > > +/* > > > > + * Functions for the access checking of the regions > > > > + */ > > > > + > > > > +static void damon_mkold(struct mm_struct *mm, unsigned long addr) > > > > +{ > > > > + pte_t *pte = NULL; > > > > + pmd_t *pmd = NULL; > > > > + spinlock_t *ptl; > > > > + > > > > + if (follow_pte_pmd(mm, addr, NULL, &pte, &pmd, &ptl)) > > > > + return; > > > > + > > > > + if (pte) { > > > > + if (pte_young(*pte)) { > > > > + clear_page_idle(pte_page(*pte)); > > > > + set_page_young(pte_page(*pte)); > > > > > > While this compiles without support for PG_young and PG_idle, I assume > > > it won't work well because it'd clear pte.young without setting > > > PG_young. And this would mess with vmscan. > > > > You're right, thanks for catching this up! This definitely need to be fixed in > > the next spin. > > > > > > > > So this code appears to depend on PG_young and PG_idle, which are > > > currently only available via CONFIG_IDLE_PAGE_TRACKING. DAMON could > > > depend on CONFIG_IDLE_PAGE_TRACKING via Kconfig. But I assume that > > > CONFIG_IDLE_PAGE_TRACKING and CONFIG_DAMON cannot be concurrently used > > > because they'll stomp on each other's use of pte.young, PG_young, > > > PG_idle. > > > So I suspect we want: > > > 1. CONFIG_DAMON to depend on !CONFIG_IDLE_PAGE_TRACKING and vise-versa. > > > 2. PG_young,PG_idle and related helpers to depend on > > > CONFIG_DAMON||CONFIG_IDLE_PAGE_TRACKING. > > > > Awesome insights and suggestions, thanks! > > > > I would like to note that DAMON could be interfered by IDLE_PAGE_TRACKING and > > vmscan, but not vice versa, as DAMON respects PG_idle and PG_young. This > > design came from the weak goal of DAMON. DAMON aims to provide not perfect > > monitoring but only best effort accuracy that would be sufficient for > > performance-centric DRAM level memory management. So, at that time, I thought > > being interfered by IDLE_PAGE_TRACKING and the reclaim logic would not be a > > real problem but letting IDLE_PAGE_TRACKING coexist is somehow beneficial. > > That said, I couldn't find a real benefit of the coexistance yet, and the > > problem of being interference now seems bigger as we will support more cases > > including the page granularity. > > > > Maybe we could make IDLE_PAGE_TRACKING and DAMON coexist but mutual exclusive > > in runtime, if the beneficial of coexistance turns out big. However, I would > > like to make it simple first and optimize the case later if real requirement > > found. > > If you are planning to have support for tracking at page granularity > and physical memory monitoring in DAMON then I don't see any benefit > of coexistence of DAMON with IDLE_PAGE_TRACKING. Though I will not > push you to go that route if the code with coexistence is simple > enough. Agreed, I don't see the benefit, neither. I already selected the mutual exclusive way :) Thanks, SeongJae Park