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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 DBA06C2D0A8 for ; Wed, 23 Sep 2020 17:05:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32C1E20BED for ; Wed, 23 Sep 2020 17:05:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="m+5t6/WR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32C1E20BED Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5A9556B0055; Wed, 23 Sep 2020 13:05:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 558556B005A; Wed, 23 Sep 2020 13:05:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 446EE6B005C; Wed, 23 Sep 2020 13:05:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 2C7F06B0055 for ; Wed, 23 Sep 2020 13:05:32 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DEF101875C26C for ; Wed, 23 Sep 2020 17:05:31 +0000 (UTC) X-FDA: 77294952462.22.wound84_480d09727158 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id A6615180AC2B0 for ; Wed, 23 Sep 2020 17:05:28 +0000 (UTC) X-HE-Tag: wound84_480d09727158 X-Filterd-Recvd-Size: 7872 Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Sep 2020 17:05:10 +0000 (UTC) Received: by mail-lf1-f67.google.com with SMTP id u8so735240lff.1 for ; Wed, 23 Sep 2020 10:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e4dEeErX3fsJf6YfVdhDLGuUkUQWGltXcsACjrY/uUI=; b=m+5t6/WReDb3eJGSXP+SUuLUwfRUdODd/gkzMeTwF+vQXEDdtXpZ8z0pgCktidjkqk dex5yOo+KZyYZt/RngNJ03vEPmDiKY3E6Rs4mxpYyUot6d8Pb2RWyI1hI3bhHzEwjIXC FbODuVFocd5UQvROdQS52y2Q5RL+//IYAHs9u9nL2lxRY/vSWnKlPmCaC8N4iirqRmrP 1RPzrLASW/3/fZQQEHL3ngFIxi/nWH0rIyY+RwDL7FZDsrQs8f1zsXwnhT2eoVSBZjL+ 6b8hFmiVlFaDmmzvZerKvOJ8l/WtRB1yCuow/q7JzeskhwQo2zn64WHaob2SmO5I0GdU NI6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4dEeErX3fsJf6YfVdhDLGuUkUQWGltXcsACjrY/uUI=; b=oLbZfWODCt8HJJHBn3llrLnR8KtlPi+7T9YpzblS8eeDYIyhqkhgNIxW33h0SKyIzN FAh/B4eFgG7Yz98yhDHB2HdymGRaNZGE0lEONr63U54GTAAkU/QPm3iokq558pllQJ2L 3u+nvh9wPYorbkaryw/FzJ69mhvmWB1UYCsnwJOziy9IBW2TdfGJzhhHvBWVf7vovrxN 0Ct8SvPnxhVr1vV369XAeL2CR5kqNeNH9PGn/Q2GRH7xvjLNtw1Jf2oz1YRfu8UwAMMQ CgnCkCH1hx1KG++uGpJVG6IJXVBILc33GEb3PcSuqXi757OLZ9auvsVvrApmBcU4fXyz G3Gg== X-Gm-Message-State: AOAM533ZE1EkvLi/66FP5G/eAhjTg0CImU1BC8gDkQBUrEaFyoWkrnI0 PNJVVOxRIDa0lTzIa4TCP98Yr7mYlHeMW3Wc6TkQRg== X-Google-Smtp-Source: ABdhPJxyVSTU6OwDrnwBr27zTvXQW3Cc+Jmn5hKL9YGv53XywBc2KXEux75LUE51dxjMmNkE1Wk1wlrvd7lleGb/XqQ= X-Received: by 2002:a05:6512:304a:: with SMTP id b10mr229017lfb.475.1600880708833; Wed, 23 Sep 2020 10:05:08 -0700 (PDT) MIME-Version: 1.0 References: <20200817105137.19296-1-sjpark@amazon.com> In-Reply-To: <20200817105137.19296-1-sjpark@amazon.com> From: Shakeel Butt Date: Wed, 23 Sep 2020 10:04:57 -0700 Message-ID: Subject: Re: [PATCH v20 00/15] Introduce Data Access MONitor (DAMON) To: SeongJae Park Cc: Andrew Morton , SeongJae Park , Jonathan.Cameron@huawei.com, Andrea Arcangeli , acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendan.d.gregg@gmail.com, Brendan Higgins , Qian Cai , Colin Ian King , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, "Du, Fan" , foersleo@amazon.de, Greg Thelen , Ian Rogers , jolsa@redhat.com, "Kirill A. Shutemov" , mark.rutland@arm.com, Mel Gorman , Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Randy Dunlap , Rik van Riel , David Rientjes , Steven Rostedt , rppt@kernel.org, sblbir@amazon.com, shuah@kernel.org, sj38.park@gmail.com, snu@amazon.de, Vlastimil Babka , Vladimir Davydov , Yang Shi , Huang Ying , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" 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 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. 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. 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. 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. I will go through individual patches to provide more detailed feedback, so, you don't need to post the next version until then. thanks, Shakeel