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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT 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 2F45FC432BE for ; Thu, 26 Aug 2021 17:29:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C6B2161058 for ; Thu, 26 Aug 2021 17:29:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C6B2161058 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 6F6D98D0002; Thu, 26 Aug 2021 13:29:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CF7B8D0001; Thu, 26 Aug 2021 13:29:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 596038D0002; Thu, 26 Aug 2021 13:29:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 40AA68D0001 for ; Thu, 26 Aug 2021 13:29:28 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D40161842DD7E for ; Thu, 26 Aug 2021 17:29:27 +0000 (UTC) X-FDA: 78517918374.01.F93ACDA Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by imf09.hostedemail.com (Postfix) with ESMTP id 926863000115 for ; Thu, 26 Aug 2021 17:29:27 +0000 (UTC) Received: by mail-qk1-f181.google.com with SMTP id bk29so4206577qkb.8 for ; Thu, 26 Aug 2021 10:29:27 -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=uF5IFoYHsR1lZIdnu6gTDDCluDFUW1Epl5M96Qr9kxs=; b=ArC8parQi12aPAfGoWzk0aeT0/zBlsU/OKeV0nbEI853NSXsshbHSO6/XC8zsGwuV0 roG3jz8IxDyobLNm3JTIe/48VHLM/2nJ8AwHyiERUgW5xvhqgmrezuaEXUOnhU3eOK14 7fEun9RzNj+I18Ikg2PMT4LDLoyX5b35oTF87KTq30kFIyfnJI7qmqP8Kvg1tmC2Zwg2 5BYjeTRO4zVVfI0sB5Sq4q4oZnd+Wt0VZV/cA3jcRq2flp4ue+rzHlkIVb795VrzlllZ pT2rixtv9jQtb1sTXwh3H7qoo3bP8nDP/0PpasCNv4MK7vLVWmmfkFRal7i+yiF9dcSU rLxg== 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=uF5IFoYHsR1lZIdnu6gTDDCluDFUW1Epl5M96Qr9kxs=; b=lYKvcT/Hn4Iv1BYguXgNEVUgywfyw4RHITbQiWA7uA1s+WtfPPUTtKFTxnBqHe7nLd T74HkLlOyGc4qyTYDHYK30NX/IVg2Yfu2TyiSHV1DVUsURmlDcNPGxBeVNTBowXCczRD R2BDkRSEZ6yKwKSSfxqJClGMnH1sEe2DSnpvUZ5CWngHYQyG/2IfjKYU4p7u6ur3Qsc5 FveSSTbwc3dIGa5ENUsdatvLoW1pRTqyb20WaNcM+ahkzc3JA6gdAMdhEXN2W91PkKAY HfZHB72RvE+223sLCTQ5mAXDKbYxi4Y+2LSyv0W1QKtn9UuyzQUqszYnw9Tw7fam0NrA slWQ== X-Gm-Message-State: AOAM530fmCtGfWzKRk8gXJCQoQ4qDeo6KKKsi+UOGTLAK7Lb6CljmAwJ sFtJjnYIKlDo6ZGQ/WHfUPI= X-Google-Smtp-Source: ABdhPJwwp98OJiE98pn+DKCzl2a89Oo78632vYbCnYS/SR5C3S62oww9ACKrOsiM726DTP58T16ayQ== X-Received: by 2002:a05:620a:1aa7:: with SMTP id bl39mr5140925qkb.304.1629998966866; Thu, 26 Aug 2021 10:29:26 -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 d78sm2728885qkg.92.2021.08.26.10.29.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Aug 2021 10:29:26 -0700 (PDT) From: SeongJae Park X-Google-Original-From: SeongJae Park To: David Hildenbrand Cc: SeongJae Park , akpm@linux-foundation.org, markubo@amazon.com, 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, dwmw@amazon.com, elver@google.com, fan.du@intel.com, foersleo@amazon.de, greg@kroah.com, gthelen@google.com, guoju.fgj@alibaba-inc.com, jgowans@amazon.com, joe@perches.com, mgorman@suse.de, mheyne@amazon.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, sieberf@amazon.com, snu@zelle79.org, 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 Subject: Re: [PATCH v34 05/13] mm/damon: Implement primitives for the virtual memory address spaces Date: Thu, 26 Aug 2021 17:29:20 +0000 Message-Id: <20210826172920.4877-1-sjpark@amazon.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <358fa060-7702-d523-5169-f25a3de0c22e@redhat.com> Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=ArC8parQ; spf=pass (imf09.hostedemail.com: domain of sj38park@gmail.com designates 209.85.222.181 as permitted sender) smtp.mailfrom=sj38park@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: t7akhmdar19xjd98s7nn5p4k4dh4ewfj X-Rspamd-Queue-Id: 926863000115 X-Rspamd-Server: rspam04 X-HE-Tag: 1629998967-820423 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 Hello David, On Thu, 26 Aug 2021 16:09:23 +0200 David Hildenbrand wrote: > > +static void damon_va_mkold(struct mm_struct *mm, unsigned long addr) > > +{ > > + pte_t *pte = NULL; > > + pmd_t *pmd = NULL; > > + spinlock_t *ptl; > > + > > I just stumbled over this, sorry for the dumb questions: Appreciate for the great questions! > > > a) What do we know about that region we are messing with? > > AFAIU, just like follow_pte() and follow_pfn(), follow_invalidate_pte() > should only be called on VM_IO and raw VM_PFNMAP mappings in general > (see the doc of follow_pte()). Do you even know that it's within a > single VMA and that there are no concurrent modifications? We have no idea about the region at this moment. However, if we successfully get the pte or pmd under the protection of the page table lock, we ensure the page for the pte or pmd is a online LRU-page with damon_get_page(), before updating the pte or pmd's PAGE_ACCESSED bit. We release the page table lock only after the update. And concurrent VMA change doesn't matter here because we read and write only the page table. If the address is not mapped or not backed by LRU pages, we simply treat it as not accessed. > > b) Which locks are we holding? > > I hope we're holding the mmap lock in read mode at least. Or how are you > making sure there are no concurrent modifications to page tables / VMA > layout ... ? > > > + if (follow_invalidate_pte(mm, addr, NULL, &pte, &pmd, &ptl)) All the operations are protected by the page table lock of the pte or pmd, so no concurrent page table modification would happen. As previously mentioned, because we read and update only page table, we don't care about VMAs and therefore we don't need to hold mmap lock here. Outside of this function, DAMON reads the VMAs to know which address ranges are not mapped, and avoid inefficiently checking access to the area with the information. Nevertheless, it happens only occasionally (once per 60 seconds by default), and it holds the mmap read lock in the case. Nonetheless, I agree the usage of follow_invalidate_pte() here could make readers very confusing. It would be better to implement and use DAMON's own page table walk logic. Of course, I might missing something important. If you think so, please don't hesitate at yelling to me. Thanks, SJ > > > > -- > Thanks, > > David / dhildenb