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 93A6BC2BB41 for ; Tue, 16 Aug 2022 06:37:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D397B8D0002; Tue, 16 Aug 2022 02:37:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEA828D0001; Tue, 16 Aug 2022 02:37:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB0008D0002; Tue, 16 Aug 2022 02:37:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AB7A38D0001 for ; Tue, 16 Aug 2022 02:37:25 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7913414021F for ; Tue, 16 Aug 2022 06:37:25 +0000 (UTC) X-FDA: 79804499250.24.AC7151E Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by imf08.hostedemail.com (Postfix) with ESMTP id 1DFC81601CD for ; Tue, 16 Aug 2022 06:37:24 +0000 (UTC) Received: by mail-vs1-f41.google.com with SMTP id m67so9224336vsc.12 for ; Mon, 15 Aug 2022 23:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=1yicZUCBmbFEVGigqV5LTF45IjTIyj4GqkBuHOHX0Mk=; b=VOIn675SBgW64Opt8anvR1hqciGXGOG56uHHdbFT8iNLi6aJg7kHNNA1GwwEjJ8fn1 pp7V/B1TiTqnokcmXLlutO9Z52E8LDcLjqXsD8ByLfjRB97ieoOsNCINYMEJ1axwFg2E b40ImzY+QYphFolCB0U5CIL/3IwXeISUA+CmfHp9mzgZeMzN6VctA2UIIzleh0naVKos vrqDUC70UE9ZPFxMLHzbJrDjc9M19oceVKBkI7FPebz2g7i7gol6U/oGk70tvc7DGrLa psRKCx0eYJHD3EceFnp12yFBFE9+SzQqcEn5B6mQI27yPbb1YCR4oF9UYxxjAHgX0qrW GJvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=1yicZUCBmbFEVGigqV5LTF45IjTIyj4GqkBuHOHX0Mk=; b=C30y5Z5/3NRob/2eUdioxK5tZ08z26Tm0g/Bm5HatziAFeQzMi38E77CiNzlTTIVBg PNKGmJK+FVaqX0QDOJDfMmw/kf6KTKET5m7MoTx/5qgnkbdHlUFcONYqLaUwB8pThVl6 ZwrEiz27Ky7nyDuEZafyXiSDbljbe3iHv7W5Yl0Q3gktkr8QCm/ug4f4uEncUJ5b1pAf 2ZWIYa6s5Y78JEluhv+b7HtCblPPUpUV8uLt/+sx1s1aNGOGLSWL3qLiV5e0/OpUa45R vPEpulBTVCDUzFkcYq93CbRONmQK/OyrSnLGAQohieFYcX4J2jNRH8Z/59aY/RSiuDtf YD8g== X-Gm-Message-State: ACgBeo2xLf4bIOO1njzHMobxLBhG93SHG1egyv5nHOTQvgP9HG0yRGML a3KmvGK2p/3uOVXvYucMb1C7LDHiMCxXYA2lhwk= X-Google-Smtp-Source: AA6agR4fxRyxPLFJx4wzCAgoPWh8+b54IujHwsnMfX6kuGqAc1R9t0Xi/hz+90IbY1JVV8tKQTFMC/NQS1/UkPfgQjk= X-Received: by 2002:a67:cb93:0:b0:388:494d:4419 with SMTP id h19-20020a67cb93000000b00388494d4419mr7709168vsl.28.1660631844358; Mon, 15 Aug 2022 23:37:24 -0700 (PDT) MIME-Version: 1.0 References: <87r11gvrx6.fsf@nvdebian.thelocal> In-Reply-To: <87r11gvrx6.fsf@nvdebian.thelocal> From: huang ying Date: Tue, 16 Aug 2022 14:37:12 +0800 Message-ID: Subject: Re: [PATCH 1/2] mm/migrate_device.c: Copy pte dirty bit to page To: Alistair Popple Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, "Sierra Guiza, Alejandro (Alex)" , Felix Kuehling , Jason Gunthorpe , John Hubbard , David Hildenbrand , Ralph Campbell , Matthew Wilcox , Karol Herbst , Lyude Paul , Ben Skeggs , Logan Gunthorpe , linuxram@us.ibm.com, paulus@ozlabs.org, Peter Xu Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660631845; a=rsa-sha256; cv=none; b=BQJZsyUJq09kHrtNn5FS4wO+WunhRUIzg8YGCM2Iqw9VcK7Sbudk/hV6gvvs4QFJgyKss7 DidyMiYwRKzdwUum1KULM/drGoHi1SpjjlZ+E+Smmg3Z2uByTkIFSiJEmE7kAopsB6PzG1 hoj3nZjBcjvrjJE4dR6kSvjv6xyjTC4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VOIn675S; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of huang.ying.caritas@gmail.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=huang.ying.caritas@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660631845; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1yicZUCBmbFEVGigqV5LTF45IjTIyj4GqkBuHOHX0Mk=; b=nK53xJtNZBlsDHQ9mmLSRKFldwLcS1lbc1zS3oh53X1321tq0g6shVTNT7Gcknpg3NeVqo HJZqerdrKZ2+JSYiNhlqlGYSG/I6vfxlNWqQDdgeMCWKcVsKRV56La6cNWffzqzYaMoBQ5 lEo/7MVCykPlRvO0YqQLjysp4GtM114= X-Stat-Signature: jzay8bq6y53wmsxgha3jgqor1pyb6gzr X-Rspamd-Queue-Id: 1DFC81601CD Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VOIn675S; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of huang.ying.caritas@gmail.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=huang.ying.caritas@gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1660631844-253772 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 Tue, Aug 16, 2022 at 10:33 AM Alistair Popple wrote: > > > huang ying writes: > > > Hi, Alistair, > > > > On Fri, Aug 12, 2022 at 1:23 PM Alistair Popple wrote: [snip] > > > And I don't know why we use ptep_get_and_clear() to clear PTE if > > (!anon_exclusive). Why don't we need to flush the TLB? > > We do the TLB flush at the end if anything was modified: > > /* Only flush the TLB if we actually modified any entries */ > if (unmapped) > flush_tlb_range(walk->vma, start, end); > > Obviously I don't think that will work correctly now given we have to > read the dirty bits and clear the PTE atomically. I assume it was > originally written this way for some sort of performance reason. Thanks for pointing this out. If there were parallel page table operations such as mprotect() or munmap(), the delayed TLB flushing mechanism here may have some problem. Please take a look at the comments of flush_tlb_batched_pending() and TLB flush batching implementation in try_to_unmap_one(). We may need to flush TLB with page table lock held or use a mechanism similar to that in try_to_unmap_one(). Best Regards, Huang, Ying