Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3258671rwb; Mon, 15 Aug 2022 22:32:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR5BkYIc/VTWarx+2H96iWtYrENmXB8PiftU+Zp2nHj+iDURdipgCOIobgSyfsjlTcJM4Cuf X-Received: by 2002:a17:902:7c05:b0:16d:2c63:da90 with SMTP id x5-20020a1709027c0500b0016d2c63da90mr20199175pll.27.1660627922857; Mon, 15 Aug 2022 22:32:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660627922; cv=none; d=google.com; s=arc-20160816; b=VmCXWmb7OKST5cEGWpm0N0qNWCfwLWNXG/kepZ/nyy54CfIfXJuRV0vrc/mvFtd9uK Hchn7zl5/Xs4E++Z49r0LEM3DCTKuL4ZO+4qJ+ZbTYoIQ8dh0xwOAtKnw7pwlvmj1QvR nwTkyGa1jCkl6jyRTvagnbVfC7RYoXISSC7XfIXUwvEPy1P9qhEAULWPlVzmjywiE0e5 FqaY5r/+f9V8vRLZKdyFqTJTnOUcmS01MFlvEZawA0+fgs98Ydp7AxrnV+lHW5cIt/j9 TAR3EKFJLNjH+UcDMHhyaqASiMX4n8pKy5N6J3w94MrRv8kE6ClK0iU+NjGN9qOYHbKm 6avg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=c+KhdgocO4zsjTWrfEV5k5L4Uxolaa6Gk/jRei7Y/Oc=; b=M2P5Yi+NgDVnIVo3JUzCy1EfnoUoWgAkbTGw6AYBGW/OzNuA9ytHPYM7EwQME8ATYF gWkaekw6dWvDKox1+XInUVmA9SV39NPJAJauAueOMaX3ysYBOIQGpZ6iynFEnq8+9xfQ 4plBkZJyM3BqcIU7gLtVqrEkbZpA1vKVI54WcG5YqlXTB6xcNvAyE2nJ2YE02PF9PNet gOr80TxErIQXWH6r7ygNUl4v2qEQMcB9tHtFQcUMN7+POdv1XSBYESMQyotSBpTJVTVL xaH5dODCY0gJhiLRgkNSd4MZSM7jsRL702is6y6sws8x3sJ+l76yLYq3r75PwaGGBefZ IvOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=TS0+ZzP9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j1-20020a63fc01000000b0041b539aec98si12211077pgi.816.2022.08.15.22.31.51; Mon, 15 Aug 2022 22:32:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=TS0+ZzP9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232353AbiHPE4c (ORCPT + 99 others); Tue, 16 Aug 2022 00:56:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233885AbiHPEzp (ORCPT ); Tue, 16 Aug 2022 00:55:45 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 758D11A6246 for ; Mon, 15 Aug 2022 13:52:53 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id r69so7490931pgr.2 for ; Mon, 15 Aug 2022 13:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc; bh=c+KhdgocO4zsjTWrfEV5k5L4Uxolaa6Gk/jRei7Y/Oc=; b=TS0+ZzP9+U3VDMoCF/KWdxpkXkeK9XBjuv9Qdin0izW547qxfmT/bA8xx8wwbmRPMm YyFvlXPDcb6xeyzuuSZDKfFQKR10Ww7hlSNSuWjku2HbH5tCvGdTad7S0zdd/exgT3Kp DkK4/aWC25K2HvXNWn8tHyUzcfbT+pB+7idD9/9SgIxfRJ5pHqTz9Jo8n+NT0fyVGIgw QYuKP8CDazls33bgYYwojsdwRcP+pKigDbNeoXK9tC0bRsPLjSnXrv5j0leIwJrCMiUk 4jQvMS6q3J3P2CwxlMjJH/k948lSu4TjZYlZXfrN5CQEgANr0UvLmqB7qtsyUPvvrNr9 cUYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc; bh=c+KhdgocO4zsjTWrfEV5k5L4Uxolaa6Gk/jRei7Y/Oc=; b=MO2Fx7OJrDxJQl958OzLF8LqRwvTofQWIk6Ia+R/dQ9KpDQxOzHQ/MCH9tTRSxDwgV gY+w+jAubIXcNkxX0VIiAkSBoEcvyrzHAFsNPerBNLrTxqR8XWTsAtW4pR9CSQEulnUC SqlXEYc1A/N0FQMZgMK2E5xPE4Ky89N0WUWzr/mnL0BcrGqR2mAHCOMJ5hsdWTzP8OSk C+XpOy8qVQU+cCPV+487TsgTsJvHlC10IgYfg6xcUbtZalsOCCwAht1kbGZhdnyzXYVw HLaPGaV6NifAhqT/kurMTOdbWjOZ8ef0SUj4XLgiDXoFMmN8BzOWoe6xXp2rxP1ElMfa 5FQQ== X-Gm-Message-State: ACgBeo0nCMeTb8GRYI3JZ5OSqJLtAvu9qp54BhWCz6b2ra8FFCnC7Ltt /ba66Snln0l67rNw0NficcI= X-Received: by 2002:a63:cf0d:0:b0:429:983d:272a with SMTP id j13-20020a63cf0d000000b00429983d272amr1746473pgg.209.1660596772468; Mon, 15 Aug 2022 13:52:52 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id q2-20020a170902f78200b0016d1f474653sm7437465pln.52.2022.08.15.13.52.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2022 13:52:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH v3 5/7] mm: Remember young/dirty bit for page migrations From: Nadav Amit In-Reply-To: Date: Mon, 15 Aug 2022 13:52:49 -0700 Cc: "Huang, Ying" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , David Hildenbrand , Andrew Morton , Hugh Dickins , Vlastimil Babka , Andrea Arcangeli , Andi Kleen , "Kirill A . Shutemov" Content-Transfer-Encoding: quoted-printable Message-Id: <5B21352C-2BE6-4070-BB6B-C1B7A5D4D225@gmail.com> References: <20220809220100.20033-1-peterx@redhat.com> <20220809220100.20033-6-peterx@redhat.com> <87pmh6dwdr.fsf@yhuang6-desk2.ccr.corp.intel.com> To: Peter Xu X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Aug 15, 2022, at 12:18 PM, Peter Xu wrote: > On Fri, Aug 12, 2022 at 10:32:48AM +0800, Huang, Ying wrote: >> Peter Xu writes: >>=20 >>> On Tue, Aug 09, 2022 at 06:00:58PM -0400, Peter Xu wrote: >>>> diff --git a/mm/migrate_device.c b/mm/migrate_device.c >>>> index 27fb37d65476..699f821b8443 100644 >>>> --- a/mm/migrate_device.c >>>> +++ b/mm/migrate_device.c >>>> @@ -221,6 +221,10 @@ static int migrate_vma_collect_pmd(pmd_t = *pmdp, >>>> else >>>> entry =3D make_readable_migration_entry( >>>> = page_to_pfn(page)); >>>> + if (pte_young(pte)) >>>> + entry =3D = make_migration_entry_young(entry); >>>> + if (pte_dirty(pte)) >>>> + entry =3D = make_migration_entry_dirty(entry); >>>> swp_pte =3D swp_entry_to_pte(entry); >>>> if (pte_present(pte)) { >>>> if (pte_soft_dirty(pte)) >>>=20 >>> This change needs to be wrapped with pte_present() at least.. >>>=20 >>> I also just noticed that this change probably won't help anyway = because: >>>=20 >>> (1) When ram->device, the pte will finally be replaced with a = device >>> private entry, and device private entry does not yet support = A/D, it >>> means A/D will be dropped again, >>>=20 >>> (2) When device->ram, we are missing information on either A/D = bits, or >>> even if device private entries start to suport A/D, it's still = not >>> clear whether we should take device read/write into = considerations >>> too on the page A/D bits to be accurate. >>>=20 >>> I think I'll probably keep the code there for completeness, but I = think it >>> won't really help much until more things are done. >>=20 >> It appears that there are more issues. Between "pte =3D *ptep" and = pte >> clear, CPU may set A/D bit in PTE, so we may need to update pte when >> clearing PTE. >=20 > Agreed, I didn't see it a huge problem with current code, but it = should be > better in that way. >=20 >> And I don't find the TLB is flushed in some cases after PTE is = cleared. >=20 > I think it's okay to not flush tlb if pte not present. But maybe = you're > talking about something else? I think Huang refers to situation in which the PTE is cleared, still not flushed, and then A/D is being set by the hardware. At least on x86, the hardware is not supposed to do so. The only case I remember (and sometimes misremembers) is with KNL erratum, which perhaps needs to be considered: https://lore.kernel.org/all/20160708001911.9A3FD2B6@viggo.jf.intel.com/