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=-20.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 360CBC433C1 for ; Fri, 26 Mar 2021 08:30:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F16961A43 for ; Fri, 26 Mar 2021 08:30:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F16961A43 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D522B6B0036; Fri, 26 Mar 2021 04:30:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D022E6B006E; Fri, 26 Mar 2021 04:30:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B55116B0070; Fri, 26 Mar 2021 04:30:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 973536B0036 for ; Fri, 26 Mar 2021 04:30:20 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 57958A2AA for ; Fri, 26 Mar 2021 08:30:20 +0000 (UTC) X-FDA: 77961353400.11.DB08AA7 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf14.hostedemail.com (Postfix) with ESMTP id D4D79C0007C8 for ; Fri, 26 Mar 2021 08:30:16 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id g24so3705838qts.6 for ; Fri, 26 Mar 2021 01:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to; bh=ppL7UiNM5EPKfhLUPGFJ4yXtucoRX+YtBylsrtnlBdE=; b=di39DjzhlYR8Gjr50cOQwsXXkVS+TpVmYSc3oiiZi1qAHrkuPRLq83UOW3CbD1MhDB 9z73Ga3AnoKjK8hSmHcRqsnBp3EPbS/CC7JEMh28tjFtdPziTQJBrYgBHPiJJTP906mC tENTzbvn1wzwVjkgN+ND9+gOsnxASqMFa3sSfiTzrm7JTaMo1/Y2RBKq/MV/TDV+IheN yVYNYQ1P7EKDwOGZEc1VPY93AV7jn/cukQ84O7YLLXreKYghGE+QI8xN6VmNpVzX9v3z qJwidjcvS1xNpwkI5lLh+ytUtQG4t3+GPMdhrg8CCM8G/689QwVdErcxRkUXOn0QQ41G DpSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to; bh=ppL7UiNM5EPKfhLUPGFJ4yXtucoRX+YtBylsrtnlBdE=; b=Newg9CHIso31ulWz14ZxTnTk886QLbkhXxTk6h4f0tEkPOZD9Blv96ykjW8cZNcrxr lSDfveVm4SGvuUO8sVkSAs+RqCEiQAlS+mSn5nrzkcBHG0hvIDN810ZbieKZHYh73CSc +iOVpyNsec7s5IQacWFRX7jRbsDrT0GidcJtRjNRhlQMvEz+am6RTrYsBuBrtxX1lafs gDKuaejPFjFuodLhvRLWljEZLVEqlrTw+C0w8ppghIgmg7l18mLRSLNJsGTi1Hj/gJqq cyQjbx3hmONMWk/WHMqfU4f0J/XKzc28LGCyrLal45SHAdz4L29WliYxPaHi6Dlho5vb Jm4g== X-Gm-Message-State: AOAM532P2vSuMaIaQPKoOVGTSg0qBfgiQzV8TSM5szD8uQkO2Q3ap1GB YOit78wgdIgxVt8zYJaxjF0= X-Google-Smtp-Source: ABdhPJzyC5HVoXZykmjhxQedeg28FjiAzubzL2hZWu6TjP/kcUlHx/xOvjRK851fo9AtTuyZhy8OaA== X-Received: by 2002:ac8:4d95:: with SMTP id a21mr10933477qtw.304.1616747419130; Fri, 26 Mar 2021 01:30:19 -0700 (PDT) Received: from localhost.localdomain (ec2-35-169-212-159.compute-1.amazonaws.com. [35.169.212.159]) by smtp.gmail.com with ESMTPSA id s28sm6190883qkj.73.2021.03.26.01.30.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Mar 2021 01:30:18 -0700 (PDT) From: SeongJae Park X-Google-Original-From: SeongJae Park To: sj38.park@gmail.com Cc: akpm@linux-foundation.org, SeongJae Park , Jonathan.Cameron@Huawei.com, acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendanhiggins@google.com, corbet@lwn.net, david@redhat.com, dwmw@amazon.com, elver@google.com, fan.du@intel.com, foersleo@amazon.de, gthelen@google.com, mgorman@suse.de, minchan@kernel.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, riel@surriel.com, rientjes@google.com, rostedt@goodmis.org, rppt@kernel.org, shakeelb@google.com, shuah@kernel.org, snu@amazon.de, vbabka@suse.cz, vdavydov.dev@gmail.com, zgf574564920@gmail.com, linux-damon@amazon.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, guoju.fgj@alibaba-inc.com Subject: Re: [PATCH v25 05/13] mm/damon: Implement primitives for the virtual memory address spaces Date: Fri, 26 Mar 2021 08:30:06 +0000 Message-Id: <20210326083006.5632-1-sjpark@amazon.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210318100856.34715-6-sj38.park@gmail.com> X-Stat-Signature: ptnbxo7qy9tifwyqocyo791g61jxen9o X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D4D79C0007C8 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-qt1-f179.google.com; client-ip=209.85.160.179 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616747416-601256 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: From: SeongJae Park On Thu, 18 Mar 2021 10:08:48 +0000 sj38.park@gmail.com 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. > > The low level primitives for the fundamental access monitoring are > defined in two parts: > > 1. Identification of the monitoring target address range for the address > space. > 2. Access check of specific address range in the target space. > > The reference implementation for the virtual address space does the > works as below. > > PTE Accessed-bit Based Access Check > ----------------------------------- > > The implementation uses PTE Accessed-bit for basic access checks. That > is, it clears the bit for the next sampling target page and checks > whether it is set again after one sampling period. This could disturb > the reclaim logic. DAMON uses ``PG_idle`` and ``PG_young`` page flags > to solve the conflict, as Idle page tracking does. > > VMA-based Target Address Range Construction > ------------------------------------------- > > Only small parts in the super-huge virtual address space of the > processes are mapped to physical memory and accessed. Thus, tracking > the unmapped address regions is just wasteful. However, because DAMON > can deal with some level of noise using the adaptive regions adjustment > mechanism, tracking every mapping is not strictly required but could > even incur a high overhead in some cases. That said, too huge unmapped > areas inside the monitoring target should be removed to not take the > time for the adaptive mechanism. > > For the reason, this implementation converts the complex mappings to > three distinct regions that cover every mapped area of the address > space. Also, the two gaps between the three regions are the two biggest > unmapped areas in the given address space. The two biggest unmapped > areas would be the gap between the heap and the uppermost mmap()-ed > region, and the gap between the lowermost mmap()-ed region and the stack > in most of the cases. Because these gaps are exceptionally huge in > usual address spaces, excluding these will be sufficient to make a > reasonable trade-off. Below shows this in detail:: > > > > > (small mmap()-ed regions and munmap()-ed regions) > > > > > Signed-off-by: SeongJae Park > Reviewed-by: Leonard Foerster > --- > include/linux/damon.h | 13 + > mm/damon/Kconfig | 9 + > mm/damon/Makefile | 1 + > mm/damon/vaddr.c | 579 ++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 602 insertions(+) > create mode 100644 mm/damon/vaddr.c > [...] > + > +/* > + * Update regions for current memory mappings > + */ > +void damon_va_update(struct damon_ctx *ctx) > +{ > + struct damon_addr_range three_regions[3]; > + struct damon_target *t; > + > + damon_for_each_target(t, ctx) { > + if (damon_va_three_regions(t, three_regions)) > + continue; > + damon_va_apply_three_regions(ctx, t, three_regions); > + } > +} > + > +static void damon_ptep_mkold(pte_t *pte, struct mm_struct *mm, > + unsigned long addr) > +{ > + bool referenced = false; > + struct page *page = pte_page(*pte); The 'pte' could be a special mapping which has no associated 'struct page'. In the case, 'page' would be invalid. Guoju from Alibaba found the problem from his GPU setup and reported the problem to via Github[1]. I made a fix and waiting for his test results. I will squash the fix in the next version of this patch. [1] https://github.com/sjp38/linux/pull/3/commits/12eeebc6ffc8b5d2a6aba7a2ec9fb85d3c1663af [2] https://github.com/sjp38/linux/commit/f1fa22b6375ceb9ae53e9370452de0d62efd4df5 Thanks, SeongJae Park > + > + if (pte_young(*pte)) { > + referenced = true; > + *pte = pte_mkold(*pte); > + } > + > +#ifdef CONFIG_MMU_NOTIFIER > + if (mmu_notifier_clear_young(mm, addr, addr + PAGE_SIZE)) > + referenced = true; > +#endif /* CONFIG_MMU_NOTIFIER */ > + > + if (referenced) > + set_page_young(page); > + > + set_page_idle(page); > +} > + [...] > + > +static void damon_va_mkold(struct mm_struct *mm, unsigned long addr) > +{ > + pte_t *pte = NULL; > + pmd_t *pmd = NULL; > + spinlock_t *ptl; > + > + if (follow_invalidate_pte(mm, addr, NULL, &pte, &pmd, &ptl)) > + return; > + > + if (pte) { > + damon_ptep_mkold(pte, mm, addr); > + pte_unmap_unlock(pte, ptl); > + } else { > + damon_pmdp_mkold(pmd, mm, addr); > + spin_unlock(ptl); > + } > +} > + [...]