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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7E59C433EF for ; Fri, 18 Mar 2022 08:21:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FC9C8D0002; Fri, 18 Mar 2022 04:21:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3ACA28D0001; Fri, 18 Mar 2022 04:21:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24CD98D0002; Fri, 18 Mar 2022 04:21:52 -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 1122D8D0001 for ; Fri, 18 Mar 2022 04:21:52 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C7E8FA0A28 for ; Fri, 18 Mar 2022 08:21:51 +0000 (UTC) X-FDA: 79256813622.28.2A5AA99 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 50468C001A for ; Fri, 18 Mar 2022 08:21:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1647591710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0MDxVA2EwZ5Sv6QfEAtDaBAheOB5XbiWwchPRUQfQRw=; b=SJT++Ja9CSkIYt4ALBY82sKXkeG4wUeQ7VeCNpwsRZYhB4VyqdgK3Bql+Yxy3e3fgOdx/T 13xfZRW0iwAztKjqsgAUXnlfy/a1J3Mn1qcYsgr5Va1m4E9ymU9f2x8cU4UksJ2hiOyiAR lw/13orQOSmip3uD2QO2Mq4FRmK60bo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-43-f0NydHUmPeyYbm1OE2hpKw-1; Fri, 18 Mar 2022 04:21:49 -0400 X-MC-Unique: f0NydHUmPeyYbm1OE2hpKw-1 Received: by mail-wm1-f70.google.com with SMTP id a26-20020a7bc1da000000b003857205ec7cso2958159wmj.2 for ; Fri, 18 Mar 2022 01:21:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=0MDxVA2EwZ5Sv6QfEAtDaBAheOB5XbiWwchPRUQfQRw=; b=s52Iu9anwApov9YayJP9qX0G9qT0GfYAdu/XTIP4VjUi6fuJsABk/7DR24j8gwWwTM 7fnGgqtkFKYQ7qX/a8pakW1vR5gMvYYMNchxrkSIdQyZDUiPSHk9VngTTA1QjvnOIQz7 bjGwhubA/BjdwqpUryAjpNQSZtp+PlWXoSCYFSrFXDV5M5iTMM8kPxBVtNKDG4R1FGSr ohQ9ZHx+hUofDKZ04Y3xmvaX5g2joRGmHzUIffNEZKFiO15UZ8nlLxRJ2t6qlhzA42Z9 4KyhJnHd9sO5E1MOgdV4Hw9VZMFdh9rVkhqJlJQ9tmMuEa6xIzYIr8255MbNsfzFIslU TdZg== X-Gm-Message-State: AOAM533dA21flZq5X5NhcDX9cLGmsCWSi56OsdX4NluD2euAK1s3z8pn lZCr99+o9vUL7phPGaunoKnPWRfwVOlvUjN89PgW5toX9SS84izPqefJXRRSSutz2GaDnUGJHsZ dToOaFxNp03M= X-Received: by 2002:adf:fe4a:0:b0:203:fb08:11d8 with SMTP id m10-20020adffe4a000000b00203fb0811d8mr197393wrs.356.1647591708224; Fri, 18 Mar 2022 01:21:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTyuk2uv2CLh4Pacq9Jr7nZxo1WSE7M1vWg5mZnRPhyRCC1hJehrGKvC3TTnTVTHeBhNNx8A== X-Received: by 2002:adf:fe4a:0:b0:203:fb08:11d8 with SMTP id m10-20020adffe4a000000b00203fb0811d8mr197374wrs.356.1647591707858; Fri, 18 Mar 2022 01:21:47 -0700 (PDT) Received: from ?IPV6:2003:d8:2f24:9200:124e:f0bf:6f8c:cbd8? (p200300d82f249200124ef0bf6f8ccbd8.dip0.t-ipconnect.de. [2003:d8:2f24:9200:124e:f0bf:6f8c:cbd8]) by smtp.gmail.com with ESMTPSA id c124-20020a1c3582000000b00384d42a9638sm6067460wma.2.2022.03.18.01.21.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 01:21:47 -0700 (PDT) Message-ID: <8483f080-a23e-fe5d-88c2-4b32d8fda521@redhat.com> Date: Fri, 18 Mar 2022 09:21:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2] mm: add access/dirty bit on numa page fault To: maobibo , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Anshuman Khandual References: <20220317065033.2635123-1-maobibo@loongson.cn> <1c54d958-9da2-97d0-e9a8-7629d4a3f7bd@loongson.cn> From: David Hildenbrand Organization: Red Hat In-Reply-To: <1c54d958-9da2-97d0-e9a8-7629d4a3f7bd@loongson.cn> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 50468C001A X-Stat-Signature: woau6atrqojw3uzudcmgb6nempu4iusy Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SJT++Ja9; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf22.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-HE-Tag: 1647591711-865755 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 18.03.22 02:17, maobibo wrote: > > > On 03/17/2022 08:32 PM, David Hildenbrand wrote: >> On 17.03.22 07:50, Bibo Mao wrote: >>> On platforms like x86/arm which supports hw page walking, access >>> and dirty bit is set by hw, however on some platforms without >>> such hw functions, access and dirty bit is set by software in >>> next trap. >>> >>> During numa page fault, dirty bit can be added for old pte if >>> fail to migrate on write fault. And if it succeeds to migrate, >>> access bit can be added for migrated new pte, also dirty bit >>> can be added for write fault. >>> >>> Signed-off-by: Bibo Mao >>> --- >>> mm/memory.c | 21 ++++++++++++++++++++- >>> 1 file changed, 20 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/memory.c b/mm/memory.c >>> index c125c4969913..65813bec9c06 100644 >>> --- a/mm/memory.c >>> +++ b/mm/memory.c >>> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf) >>> if (migrate_misplaced_page(page, vma, target_nid)) { >>> page_nid = target_nid; >>> flags |= TNF_MIGRATED; >>> + >>> + /* >>> + * update pte entry with access bit, and dirty bit for >>> + * write fault >>> + */ >>> + spin_lock(vmf->ptl); >> >> Ehm, are you sure? We did a pte_unmap_unlock(), so you most certainly need a >> >> vmf->pte = pte_offset_map(vmf->pmd, vmf->address); > yes, we need probe pte entry again after function pte_unmap_unlock(). >> >> >> Also, don't we need pte_same() checks before we do anything after >> dropping the PT lock? > I do not think so. If page succeeds in migration, pte entry should be changed > also, it should be different. > We have to be very careful here. Page migration succeeded, so I do wonder if you have to do anything on this branch *at all*. I'd assume that page migration too care of that already. See, when only holding the mmap lock in read mode, there are absolutely no guarantees what will happen after dropping the PT lock. The page could get unmapped and another page could get mapped. The page could have been mapped R/O in the meantime. So I'm pretty sure that unconditionally modifying the PTE here is wrong. -- Thanks, David / dhildenb