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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,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 54E93C433DF for ; Wed, 27 May 2020 12:47:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 19F32208B6 for ; Wed, 27 May 2020 12:47:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="nAH6AnKE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19F32208B6 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 A0410800D9; Wed, 27 May 2020 08:47:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B42A80010; Wed, 27 May 2020 08:47:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C9A5800D9; Wed, 27 May 2020 08:47:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 7633C80010 for ; Wed, 27 May 2020 08:47:12 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2B262824556B for ; Wed, 27 May 2020 12:47:12 +0000 (UTC) X-FDA: 76862474304.25.ball74_4513a9b26d52 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 04E1E1804E3BF for ; Wed, 27 May 2020 12:47:12 +0000 (UTC) X-HE-Tag: ball74_4513a9b26d52 X-Filterd-Recvd-Size: 6694 Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 May 2020 12:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1590583632; x=1622119632; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ZpUgh+P6r6mxj1lydd2QIOZrB0EuK0mUcU82zaKuhF8=; b=nAH6AnKEVRyari6YChv2kQa47EqEFk4BXS1U2K2Ik8p4h+kH5n9jSxqZ 7xQhunlHYIQQAb2zWIGaDSjkSEElVPBLYwBix92GENfL/ZDorzN5Q2eKB avWBxkbUPWlkC/BehCsR1QM2gbVr1zoH3fpZrek5iokFal/WVVl5Adkjs 4=; IronPort-SDR: AcgyTr3N5DPmtU9JSr4a2uBZjFAZVmeCfi5HmoNti3oUI4DFnAnVdtGUQeSWDCCnAzPcO3qFp4 bwmqOJ27fgTA== X-IronPort-AV: E=Sophos;i="5.73,441,1583193600"; d="scan'208";a="38101351" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 27 May 2020 12:47:10 +0000 Received: from EX13MTAUEA002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com (Postfix) with ESMTPS id EAEAFA23F8; Wed, 27 May 2020 12:47:07 +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, 27 May 2020 12:47:07 +0000 Received: from u886c93fd17d25d.ant.amazon.com (10.43.162.53) by EX13D31EUA001.ant.amazon.com (10.43.165.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 12:46:51 +0000 From: SeongJae Park To: Leonard Foerster CC: SeongJae Park , , "SeongJae Park" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: Re: [PATCH v13 05/15] mm/damon: Adaptively adjust regions Date: Wed, 27 May 2020 14:46:35 +0200 Message-ID: <20200527124635.19577-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <1590578636-27155-1-git-send-email-foersleo@amazon.com> (raw) MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.43.162.53] X-ClientProxiedBy: EX13D15UWA002.ant.amazon.com (10.43.160.218) To EX13D31EUA001.ant.amazon.com (10.43.165.15) X-Rspamd-Queue-Id: 04E1E1804E3BF X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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, 27 May 2020 13:23:56 +0200 Leonard Foerster wrote: > On 2020-05-25T11:15:02+02:00 SeongJae Park wrote: > > > From: SeongJae Park > > > > At the beginning of the monitoring, DAMON constructs the initial regions > > by evenly splitting the memory mapped address space of the process into > > the user-specified minimal number of regions. In this initial state, > > the assumption of the regions (pages in same region have similar access > > frequencies) is normally not kept and thus the monitoring quality could > > be low. To keep the assumption as much as possible, DAMON adaptively > > merges and splits each region. > > > > For each ``aggregation interval``, it compares the access frequencies of > > adjacent regions and merges those if the frequency difference is small. > > Then, after it reports and clears the aggregated access frequency of > > each region, it splits each region into two regions if the total number > > of regions is smaller than the half of the user-specified maximum number > > of regions. > > > > In this way, DAMON provides its best-effort quality and minimal overhead > > while keeping the bounds users set for their trade-off. > > > > Signed-off-by: SeongJae Park > > --- > > [...] > > +/* > > + * splits every target region into two randomly-sized regions > > + * > > + * This function splits every target region into two random-sized regions if > > + * current total number of the regions is equal or smaller than half of the > > + * user-specified maximum number of regions. This is for maximizing the > > + * monitoring accuracy under the dynamically changeable access patterns. If a > > + * split was unnecessarily made, later 'kdamond_merge_regions()' will revert > > + * it. > > + */ > > +static void kdamond_split_regions(struct damon_ctx *ctx) > > +{ > > + struct damon_task *t; > > + unsigned int nr_regions = 0; > > + static unsigned int last_nr_regions; > > + int nr_subregions = 2; > > + > > + damon_for_each_task(t, ctx) > > + nr_regions += nr_damon_regions(t); > > + > > + if (nr_regions > ctx->max_nr_regions / 2) > > + return; > > + > > + /* If number of regions is not changed, we are maybe in corner case */ > > + if (last_nr_regions == nr_regions && > > + nr_regions < ctx->max_nr_regions / 3) > > + nr_subregions = 3; > > + > > + damon_for_each_task(t, ctx) > > + damon_split_regions_of(ctx, t, nr_subregions); > > + > > + if (!last_nr_regions) > > + last_nr_regions = nr_regions; > > So we are only setting last_nr_regions once when we first come along > here (when last_nr_regions == 0). Thus we are checking from now on if > nr_regions is the same as nr_regions was before the first ever split. So > we are doing the three-way split whenever nr_regions has come to the > initial number of regions. Is this actually what we want? The naming > suggests that we want to check against the number before the last split > to detect if we have moved into a spot where we are splitting and > merging back and forth between two states (this is the corner case we > are talking about?). > > Or am I misunderstanding the intention here? Oops, you're right, I made obvious mistake. Thank you for finding this. I will fix this in the next spin. Thanks, SeongJae Park > > Leonard