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=-8.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 0A2BAC2D0E2 for ; Thu, 24 Sep 2020 06:39:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 57613235F7 for ; Thu, 24 Sep 2020 06:39:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="M5jpnZ6e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57613235F7 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A23016B0073; Thu, 24 Sep 2020 02:39:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D42D6B0074; Thu, 24 Sep 2020 02:39:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89B3E6B0075; Thu, 24 Sep 2020 02:39:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 718A06B0073 for ; Thu, 24 Sep 2020 02:39:55 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2C579181AE863 for ; Thu, 24 Sep 2020 06:39:55 +0000 (UTC) X-FDA: 77297004750.11.part94_2d0b1c42715c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 027BF180F8B81 for ; Thu, 24 Sep 2020 06:39:54 +0000 (UTC) X-HE-Tag: part94_2d0b1c42715c X-Filterd-Recvd-Size: 8152 Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Sep 2020 06:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1600929595; x=1632465595; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=PW0B655DySKTSqtBH4LuirqSOsvQ6UdGky6VjqG365Y=; b=M5jpnZ6eI3U9mclT8MkmXxfK51slX55+5t+5fBoMGeybI5Vf0lSCG8l6 V7J5Sk/52TQaUZAHttleHWyLD82NT13NKza6Rr1sfKExuY5dzx4T2QNIw mVz7EIjFCf98gp4y8m56si0h2TtWq3xxMMX5H4SA9RJEN8aKqWFB4Izh7 4=; X-IronPort-AV: E=Sophos;i="5.77,296,1596499200"; d="scan'208";a="77594955" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-168cbb73.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 24 Sep 2020 06:39:42 +0000 Received: from EX13D31EUA004.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-168cbb73.us-west-2.amazon.com (Postfix) with ESMTPS id B322AA1BD4; Thu, 24 Sep 2020 06:39:39 +0000 (UTC) Received: from u3f2cd687b01c55.ant.amazon.com (10.43.162.35) by EX13D31EUA004.ant.amazon.com (10.43.165.161) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Sep 2020 06:39:19 +0000 From: SeongJae Park To: Shakeel Butt CC: SeongJae Park , SeongJae Park , , Andrea Arcangeli , , , , , , Brendan Higgins , Qian Cai , Colin Ian King , Jonathan Corbet , "David Hildenbrand" , , "Du, Fan" , , Greg Thelen , 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: [PATCH v20 00/15] Introduce Data Access MONitor (DAMON) Date: Thu, 24 Sep 2020 08:39:03 +0200 Message-ID: <20200924063903.12432-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.35] X-ClientProxiedBy: EX13D43UWC002.ant.amazon.com (10.43.162.172) To EX13D31EUA004.ant.amazon.com (10.43.165.161) 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: On Wed, 23 Sep 2020 10:04:57 -0700 Shakeel Butt wrote: > On Mon, Aug 17, 2020 at 3:52 AM SeongJae Park wrote: > > > > From: SeongJae Park > > > > Changes from Previous Version > > ============================= > > > > - Place 'CREATE_TRACE_POINTS' after '#include' statements (Steven Rostedt) > > - Support large record file (Alkaid) > > - Place 'put_pid()' of virtual monitoring targets in 'cleanup' callback > > - Avoid conflict between concurrent DAMON users > > - Update evaluation result document > > > > Introduction > > ============ > > > > DAMON is a data access monitoring framework subsystem for the Linux kernel. > > The core mechanisms of DAMON called 'region based sampling' and 'adaptive > > regions adjustment' (refer to 'mechanisms.rst' in the 11th patch of this > > patchset for the detail) make it > > > > - accurate (The monitored information is useful for DRAM level memory > > management. It might not appropriate for Cache-level accuracy, though.), > > - light-weight (The monitoring overhead is low enough to be applied online > > while making no impact on the performance of the target workloads.), and > > - scalable (the upper-bound of the instrumentation overhead is controllable > > regardless of the size of target workloads.). > > > > Using this framework, therefore, the kernel's core memory management mechanisms > > such as reclamation and THP can be optimized for better memory management. The > > experimental memory management optimization works that incurring high > > instrumentation overhead will be able to have another try. In user space, > > meanwhile, users who have some special workloads will be able to write > > personalized tools or applications for deeper understanding and specialized > > optimizations of their systems. > > > > Evaluations > > =========== > > > > We evaluated DAMON's overhead, monitoring quality and usefulness using 25 > > realistic workloads on my QEMU/KVM based virtual machine running a kernel that > > v20 DAMON patchset is applied. > > > > DAMON is lightweight. It increases system memory usage by 0.12% and slows > > target workloads down by 1.39%. > > > > DAMON is accurate and useful for memory management optimizations. An > > experimental DAMON-based operation scheme for THP, 'ethp', removes 88.16% of > > THP memory overheads while preserving 88.73% of THP speedup. Another > > experimental DAMON-based 'proactive reclamation' implementation, 'prcl', > > reduces 91.34% of residential sets and 25.59% of system memory footprint while > > incurring only 1.58% runtime overhead in the best case (parsec3/freqmine). > > > > NOTE that the experimentail THP optimization and proactive reclamation are not > > for production but just only for proof of concepts. > > > > Please refer to the official document[1] or "Documentation/admin-guide/mm: Add > > a document for DAMON" patch in this patchset for detailed evaluation setup and > > results. > > > > [1] https://damonitor.github.io/doc/html/latest-damon/admin-guide/mm/damon/eval.html > > > > > Hi SeongJae, > > Sorry for the late response. I will start looking at this series in > more detail in the next couple of weeks. Thank you so much! > I have a couple of high level comments for now. > > 1) Please explain in the cover letter why someone should prefer to use > DAMON instead of Page Idle Tracking. In short, because DAMON provides overhead-quality tradeoff and allow use of variable monitoring primitives other than only PG_Idle and PTE Accessed bits. I will explain this in detail in the cover letter of the next version of this patchset. > > 2) Also add what features Page Idle Tracking provides which the first > version of DAMON does not provide (like page level tracking, physical > or unmapped memory tracking e.t.c) and tell if you plan to add such > features to DAMON in future. Basically giving reasons to not block the > current version of DAMON until it is feature-rich. In short, DAMON will provide only virtual address space monitoring by default but I believe the lack of features because DAMON is expandable for those. Also, I will make DAMON co-exists with Idle Page Tracking again. I will post another RFC patchset for this soon. Again, I will describe this in detail in the next version of the cover letter. > > 3) I think in the first mergeable version of DAMON, I would prefer to > have support to control (create/delete/account) the DAMON context. You > already have a RFC series on it. I would like to have that series part > of this one. Ok, I will apply it here. Thanks, SeongJae Park