Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1055718rwe; Wed, 24 Aug 2022 14:06:27 -0700 (PDT) X-Google-Smtp-Source: AA6agR4YbmDtibtTHWETbOfncIHN4ofAsj8GBHbjSLioQ4RT5BVkeLF/kOgSm+SCm7+AN50Btabo X-Received: by 2002:a05:6402:27d2:b0:43e:3ff6:ad58 with SMTP id c18-20020a05640227d200b0043e3ff6ad58mr673897ede.234.1661375186945; Wed, 24 Aug 2022 14:06:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661375186; cv=none; d=google.com; s=arc-20160816; b=urTB8ZqSqdChuJ0VyvDwL8uAc3nVKzOQV8oq+vtk6kOJsLFIXibPZdvxRQ01LVE2K7 JWBDCkgu3IzwRK8XgM1gr5pxBPbdzrPFXyM+dayvU9dfxGUg670Sshs/sscXPPnM9D1U fHoFrewIELOrurjx/JxeG8Y/b2/n8GZ/GQWL9WZEXeofdjRzElB+kG3QkQu081Gtpewl oCTtzgVN1O9npal3Jkp81clqazYfq0VgIjqpCT2BKrR8r0/pXDN7FNEF0c6+tycoNkEY RnAY6sgKzuAHsgrLY+1RQYY/LORyaid7VOdjgJXH5+iDekT23Lvrbx5Rcy43j/QSI7jZ xA6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=WcGllBx/E+hwvIFs2WxQDGDJChMuYQJTiL0H+5A7OM0=; b=hTaAiQbp4nYJAfTVoEcaWjEjK+Ug/fgyVhuVNEPHvdP6sUqpP5Tpu4rcdB57oAK6ct YgaqH1Mo63H05WyCRUVBIsSZVDUpQ/p1ySDcSRGtpv3J4Xak2ML5emSHVx6DR/llzf7z MzRr1VDOPddtvMrRg52ju+9P6hYFYXSJJTzOi1BexZYmBMIivQO3Fe7Lg9AnDQ4IpTUA T5VkvZHr8BoRC5cwHzzdGGAkx3K/tzUFPaVvaBJAUO/rUBBLLpTH7rFn4/Y9Phdl/LlX sOO9sCa/atnRGFp9lmBBYazH3gh3OSY8txFeCW6rzQnrQUvwruQkk9qUIqkIPSYNfjJt +k3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TU36UDUF; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b4-20020a0564021f0400b0043c25d25046si3955237edb.249.2022.08.24.14.06.00; Wed, 24 Aug 2022 14:06:26 -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=@redhat.com header.s=mimecast20190719 header.b=TU36UDUF; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240350AbiHXUZz (ORCPT + 99 others); Wed, 24 Aug 2022 16:25:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240354AbiHXUZw (ORCPT ); Wed, 24 Aug 2022 16:25:52 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 934281F613 for ; Wed, 24 Aug 2022 13:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661372749; 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: in-reply-to:in-reply-to:references:references; bh=WcGllBx/E+hwvIFs2WxQDGDJChMuYQJTiL0H+5A7OM0=; b=TU36UDUF5tc3Y4XVjVatqgkZdgawz+vG3zQBs25yaq4wU4QkL7hTEK+s+drxT+Y6tCibRs nuG1MmHD0cIKaUfA6agjh+tSihzH9zGE86R51aG1o66DDqL4ZgBPELsvG5KE2GCreMQU9/ EGlBm4kIIw+Y8zvT8Gv3LlpgAMIx+ck= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-393-WLWbl_vCMC2fgS6CK-KoYQ-1; Wed, 24 Aug 2022 16:25:48 -0400 X-MC-Unique: WLWbl_vCMC2fgS6CK-KoYQ-1 Received: by mail-qv1-f71.google.com with SMTP id od16-20020a0562142f1000b00496e2ea7934so6233046qvb.13 for ; Wed, 24 Aug 2022 13:25:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=WcGllBx/E+hwvIFs2WxQDGDJChMuYQJTiL0H+5A7OM0=; b=Ep/WmcPQi8JZiLIJkRVXR1IXL7ohJ43P3aSDFoFWQbbmnB/rBJ6Ex9hr3Z3hZ6CJUv 06xIuqzA+UYi2v6gWpXWF8tO81tlLF5Fr8VYT7IDAu0q//0RMuFtXcPr4SNwY2hXy1Xe GwIFxgCdRxBEvFH0fgn1bVI8DjhtJIm6Gfk+EqW+pC61k0YDxxCvPClJZbpvuICnIYHQ Sn8xGDH0NCes98ZuBy8kS3FEzIj/Sib1bUpicRcqNnxfMSDs+iGP5NWGqk26gssjCC4O kuH096fKbrG3ivyxkoHykP5wtj3k30GHsvvwWfnSuCpXpRaXyHXDRa1p4WlnToLRIU4M ogQQ== X-Gm-Message-State: ACgBeo2bYnWF7YQ7RTthHH64b8iYGulDm3fQwLdoGyY7qXXgtZ237pRh vW01dliC3aByxKGQbNlQZpr1Xb3ZgOA88OLA7GJ9aEXmGPMc/kWNjI6dPAvJNOe4HcSAAaqHiPr 463PUZUMwzudjv5yPd7dHS6w+ X-Received: by 2002:ac8:7e83:0:b0:344:7ee0:1241 with SMTP id w3-20020ac87e83000000b003447ee01241mr889832qtj.587.1661372747563; Wed, 24 Aug 2022 13:25:47 -0700 (PDT) X-Received: by 2002:ac8:7e83:0:b0:344:7ee0:1241 with SMTP id w3-20020ac87e83000000b003447ee01241mr889808qtj.587.1661372747336; Wed, 24 Aug 2022 13:25:47 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-35-70-27-3-10.dsl.bell.ca. [70.27.3.10]) by smtp.gmail.com with ESMTPSA id v16-20020a05620a0f1000b006b97151d2b3sm16098374qkl.67.2022.08.24.13.25.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 13:25:46 -0700 (PDT) Date: Wed, 24 Aug 2022 16:25:44 -0400 From: Peter Xu To: Alistair Popple Cc: "Huang, Ying" , Nadav Amit , huang ying , Linux MM , Andrew Morton , LKML , "Sierra Guiza, Alejandro (Alex)" , Felix Kuehling , Jason Gunthorpe , John Hubbard , David Hildenbrand , Ralph Campbell , Matthew Wilcox , Karol Herbst , Lyude Paul , Ben Skeggs , Logan Gunthorpe , paulus@ozlabs.org, linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page Message-ID: References: <871qtfvdlw.fsf@nvdebian.thelocal> <87o7wjtn2g.fsf@nvdebian.thelocal> <87tu6bbaq7.fsf@yhuang6-desk2.ccr.corp.intel.com> <1D2FB37E-831B-445E-ADDC-C1D3FF0425C1@gmail.com> <87czcyawl6.fsf@yhuang6-desk2.ccr.corp.intel.com> <874jy9aqts.fsf@yhuang6-desk2.ccr.corp.intel.com> <87czcqiecd.fsf@nvdebian.thelocal> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87czcqiecd.fsf@nvdebian.thelocal> X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Wed, Aug 24, 2022 at 11:56:25AM +1000, Alistair Popple wrote: > >> Still I don't know whether there'll be any side effect of having stall tlbs > >> in !present ptes because I'm not familiar enough with the private dev swap > >> migration code. But I think having them will be safe, even if redundant. > > What side-effect were you thinking of? I don't see any issue with not > TLB flushing stale device-private TLBs prior to the migration because > they're not accessible anyway and shouldn't be in any TLB. Sorry to be misleading, I never meant we must add them. As I said it's just that I don't know the code well so I don't know whether it's safe to not have it. IIUC it's about whether having stall system-ram stall tlb in other processor would matter or not here. E.g. some none pte that this code collected (boosted both "cpages" and "npages" for a none pte) could have stall tlb in other cores that makes the page writable there. When I said I'm not familiar with the code, it's majorly about one thing I never figured out myself, in that migrate_vma_collect_pmd() has this optimization to trylock on the page, collect if it succeeded: /* * Optimize for the common case where page is only mapped once * in one process. If we can lock the page, then we can safely * set up a special migration page table entry now. */ if (trylock_page(page)) { ... } else { put_page(page); mpfn = 0; } But it's kind of against a pure "optimization" in that if trylock failed, we'll clear the mpfn so the src[i] will be zero at last. Then will we directly give up on this page, or will we try to lock_page() again somewhere? The future unmap op is also based on this "cpages", not "npages": if (args->cpages) migrate_vma_unmap(args); So I never figured out how this code really works. It'll be great if you could shed some light to it. Thanks, -- Peter Xu