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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham 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 C16C9C49EA2 for ; Tue, 22 Jun 2021 14:59:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 57E2B6137D for ; Tue, 22 Jun 2021 14:59:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57E2B6137D 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 30B776B005D; Tue, 22 Jun 2021 10:59:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BB5F6B006E; Tue, 22 Jun 2021 10:59:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 135506B0070; Tue, 22 Jun 2021 10:59:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id C17996B005D for ; Tue, 22 Jun 2021 10:59:24 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0591E8249980 for ; Tue, 22 Jun 2021 14:59:25 +0000 (UTC) X-FDA: 78281668290.04.D35C066 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf13.hostedemail.com (Postfix) with ESMTP id AC1FFE002CC7 for ; Tue, 22 Jun 2021 14:59:24 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id s22so30582150ljg.5 for ; Tue, 22 Jun 2021 07:59:24 -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=YkBx1QZ3YBUcTOVSAktKfd9SQPvUoOM5O8r05maYQAQ=; b=snHPRXQhEZNJPwQqRxZC6v8U6a8W9E2FA+po5CGY2JTudvUl8mDcAAaHoztv7MpHxX /k/Gij67GUyS2zlvi771HTGkk/7+YoktyKygOp0DvrP8aVxjnr/+PWNEfEO/2A6ylX+3 VOZARUS6Cvp1mmVceEcvU436WL50GtfhoF/UUHvb3JqcQnm6uMb3rFC3MxwKXHc96lQ6 249kcrwzOgpIFQKcldBio6d8kmI8SPk8rIIpMXhO1tLzRidXnQVqLUZFnMiGqbCJboCs tfjM8Xv/kDC4+jZf8us5mkT88LsTcGHVbmhwn4C/T8THxSUdTKypqYkgs4v1qL8xUnIe taxg== 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=YkBx1QZ3YBUcTOVSAktKfd9SQPvUoOM5O8r05maYQAQ=; b=mSBC6tXAyJOEwDZrz8E7CgkaYHqz5Q2LtJ2mC9gFWvcBeBrU78T5F3CKxPHejt303v pxm/Jaj3ZnvuE1y9XsIw6xtyyelmNgkE3MeFIuU0iDxcrv3PuHCOhkrVINfA8qb8aCz1 e2pdfHJfAJzwfw613Ttt+NfurC1RVO4hfsBnx9s1aiMrJNghbhb1D+FLEsWOgOXl22y4 xFqx9xKfwt/8NwSZ/f5amSn6bI0yNucpggAyMS4VAr5ZSvBaE6M2JVTc91SlufMxQVzd 8B7czlBS2bZVfUDAgwyXks4qgA1A5DqtzKPA0Q/pH7TxiLbThQHlIN2BKCHASB1lFegE ATog== X-Gm-Message-State: AOAM533ZEt8cZFKN9ctuo85a0VP/IjMPyu7JmBlHpeRPTrNODImeZxVY 45JppkJinvFa10MDFq0J1bOpS7QJ3avtLz06EyYIYw== X-Google-Smtp-Source: ABdhPJw24ImUKGKOxJBlWjfykDltmmZe05nzbOYLp2G/uUfjgWfVekd/NvNH3RSPY6Vo82S0GxVIslMrrGSZMbHUUvM= X-Received: by 2002:a2e:6c1a:: with SMTP id h26mr3725615ljc.34.1624373962635; Tue, 22 Jun 2021 07:59:22 -0700 (PDT) MIME-Version: 1.0 References: <20210621083108.17589-1-sj38.park@gmail.com> <20210621083108.17589-2-sj38.park@gmail.com> In-Reply-To: <20210621083108.17589-2-sj38.park@gmail.com> From: Shakeel Butt Date: Tue, 22 Jun 2021 07:59:11 -0700 Message-ID: Subject: Re: [PATCH v31 01/13] mm: Introduce Data Access MONitor (DAMON) To: SeongJae Park Cc: Andrew Morton , SeongJae Park , Jonathan.Cameron@huawei.com, acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, Brendan Higgins , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, Marco Elver , "Du, Fan" , foersleo@amazon.de, greg@kroah.com, Greg Thelen , guoju.fgj@alibaba-inc.com, jgowans@amazon.com, Mel Gorman , mheyne@amazon.de, Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Rik van Riel , David Rientjes , Steven Rostedt , Mike Rapoport , Shuah Khan , sieberf@amazon.com, snu@zelle79.org, Vlastimil Babka , Vladimir Davydov , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=snHPRXQh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of shakeelb@google.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Stat-Signature: 4xambn3q16f96gj83ap5c7b6b8i9jzde X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AC1FFE002CC7 X-HE-Tag: 1624373964-819056 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, Jun 21, 2021 at 1:31 AM SeongJae Park wrote: > > From: SeongJae Park > > DAMON is a data access monitoring framework for the Linux kernel. The > core mechanisms of DAMON make it > > - accurate (the monitoring output is useful enough for DRAM level > performance-centric memory management; It might be inappropriate for > CPU cache levels, though), > - light-weight (the monitoring overhead is normally low enough to be > applied online), and > - scalable (the upper-bound of the overhead is in constant range > regardless of the size of target workloads). > > Using this framework, hence, we can easily write efficient kernel space > data access monitoring applications. For example, the kernel's memory > management mechanisms can make advanced decisions using this. > Experimental data access aware optimization works that incurring high > access monitoring overhead could again be implemented on top of this. > > Due to its simple and flexible interface, providing user space interface > would be also easy. Then, user space users who have some special > workloads can write personalized applications for better understanding > and optimizations of their workloads and systems. > > === > > Nevertheless, this commit is defining and implementing only basic access > check part without the overhead-accuracy handling core logic. The basic > access check is as below. > > The output of DAMON says what memory regions are how frequently accessed > for a given duration. The resolution of the access frequency is > controlled by setting ``sampling interval`` and ``aggregation > interval``. In detail, DAMON checks access to each page per ``sampling > interval`` and aggregates the results. In other words, counts the > number of the accesses to each region. After each ``aggregation > interval`` passes, DAMON calls callback functions that previously > registered by users so that users can read the aggregated results and > then clears the results. This can be described in below simple > pseudo-code:: > > init() > while monitoring_on: > for page in monitoring_target: > if accessed(page): > nr_accesses[page] += 1 > if time() % aggregation_interval == 0: > for callback in user_registered_callbacks: > callback(monitoring_target, nr_accesses) > for page in monitoring_target: > nr_accesses[page] = 0 > if time() % update_interval == 0: regions_update_interval? > update() > sleep(sampling interval) > > The target regions constructed at the beginning of the monitoring and > updated after each ``regions_update_interval``, because the target > regions could be dynamically changed (e.g., mmap() or memory hotplug). > The monitoring overhead of this mechanism will arbitrarily increase as > the size of the target workload grows. > > The basic monitoring primitives for actual access check and dynamic > target regions construction aren't in the core part of DAMON. Instead, > it allows users to implement their own primitives that are optimized for > their use case and configure DAMON to use those. In other words, users > cannot use current version of DAMON without some additional works. > > Following commits will implement the core mechanisms for the > overhead-accuracy control and default primitives implementations. > > Signed-off-by: SeongJae Park > Reviewed-by: Leonard Foerster > Reviewed-by: Fernand Sieber Few nits below otherwise look good to me. You can add: Acked-by: Shakeel Butt [...] > +/* > + * __damon_start() - Starts monitoring with given context. > + * @ctx: monitoring context > + * > + * This function should be called while damon_lock is hold. > + * > + * Return: 0 on success, negative error code otherwise. > + */ > +static int __damon_start(struct damon_ctx *ctx) > +{ > + int err = -EBUSY; > + > + mutex_lock(&ctx->kdamond_lock); > + if (!ctx->kdamond) { > + err = 0; > + ctx->kdamond_stop = false; > + ctx->kdamond = kthread_create(kdamond_fn, ctx, "kdamond.%d", > + nr_running_ctxs); > + if (IS_ERR(ctx->kdamond)) > + err = PTR_ERR(ctx->kdamond); > + else > + wake_up_process(ctx->kdamond); Nit: You can use kthread_run() here. > + } > + mutex_unlock(&ctx->kdamond_lock); > + > + return err; > +} > + [...] > +static int __damon_stop(struct damon_ctx *ctx) > +{ > + mutex_lock(&ctx->kdamond_lock); > + if (ctx->kdamond) { > + ctx->kdamond_stop = true; > + mutex_unlock(&ctx->kdamond_lock); > + while (damon_kdamond_running(ctx)) > + usleep_range(ctx->sample_interval, > + ctx->sample_interval * 2); Any reason to not use kthread_stop() here?