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 5FEF6C3F6B0 for ; Wed, 24 Aug 2022 20:25:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D764B940007; Wed, 24 Aug 2022 16:25:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFEBB6B0075; Wed, 24 Aug 2022 16:25:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B775E940007; Wed, 24 Aug 2022 16:25:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A25376B0074 for ; Wed, 24 Aug 2022 16:25:50 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6DA198131F for ; Wed, 24 Aug 2022 20:25:50 +0000 (UTC) X-FDA: 79835617260.24.1A67D7C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 720041C000C for ; Wed, 24 Aug 2022 20:25:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661372748; 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=bBbbpZe0RCwAgqJbYBmRekFy9cXSY7WDT4vRKsJ6/c9GpaN3XYfsS5IgIJCcAJ2mJXn0/Z JKYuHEbGOvsqL64iE50B71nz/wV0EovqGzxfYrEFQvoD+Bar5OwyZHa3KcR+oPGPs2/05E 7kpZEB3RoNK5MZaKDeDAvO8U5r6vITs= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-300-HwTovD4wNpqu6Xvdvuuxig-1; Wed, 24 Aug 2022 16:25:48 -0400 X-MC-Unique: HwTovD4wNpqu6Xvdvuuxig-1 Received: by mail-qt1-f197.google.com with SMTP id ff27-20020a05622a4d9b00b0034306b77c08so13588311qtb.6 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=klKin/9M7Pf5yK2iJScMpGtZIk7QbC0dG6MBuA0nHiz8u7QaZhm2U6bRy9grz1ZSZi ndBq4xtiWP3pdtQI3A5QaJ1fv3WKkE93397umZDBZCltp8XDV8EbC8ByF/nej9hbjbS8 N/vxczJGTzqDLpr7K7Yeq9nBmBb9LmgyZlGrKwieOJ6JoVDpqV0uLKFPD2Q6knbxRN/g +UjAcsHB0Z0t8cwayrnVPaifQ7s9LsqPQb3pnBVQlAobss5FJIKSsyD+vbVHVWeYwUR+ Htu3QopUWXE34T792m/WnWaGjDjHkeik8UyLtBt4E1SJmj4eqLsvRM9tTnUtSqTfhDa5 VFJA== X-Gm-Message-State: ACgBeo1nnHBb/BtRFcBbybmblLLQ0tOQwFNbX5SPpjB6aUreD7gmkg3q xsSnnzm4LUlOmj+3EDuH1FzClWvrjAaHtNcyblajbDPjrw8WKtH39t+pIj0NfFemvEde48RYcsm qoCQAeQbcF+g= X-Received: by 2002:ac8:7e83:0:b0:344:7ee0:1241 with SMTP id w3-20020ac87e83000000b003447ee01241mr889830qtj.587.1661372747562; Wed, 24 Aug 2022 13:25:47 -0700 (PDT) X-Google-Smtp-Source: AA6agR4At86RE03P4mlSnr4jeclId4tDLoIpgKf+KL9cAcwLzF1s7WEI2JSHt6UJKgXWx7E14+/57Q== 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 In-Reply-To: <87czcqiecd.fsf@nvdebian.thelocal> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661372750; a=rsa-sha256; cv=none; b=waY9gi7PW2wKCvk5RH7oiHPL4gTKOBgdZg4c64DwXRa52ZYSlvaKMxzkgmu8dbkooLYBLq 2gWidCqNnfU8ywh8CD7ACNZwJ/TBJEqJgCcKXx/gJSt9gQcQtRONOJlhh90O25jw1HeXa3 cBc7P/+C7uwrEiO/W0gO4CmXAidqxiA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bBbbpZe0; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661372750; 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=WcGllBx/E+hwvIFs2WxQDGDJChMuYQJTiL0H+5A7OM0=; b=vLNG67ZsEP62cPaxTaPy3S3CEw49cqFhSVEeME+l9aa251wUIEqjMG0GUKcgsdn7bhbhcc VYDUhcgb24K0ucZYo7EEuVZmcCenh217Dp8SxeOyOvFYBtvmDhvsc8rlHwo4daiDeiUtEB 2Xk12lYS8beqGNii1HUPXSOqqdqRtps= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 720041C000C X-Stat-Signature: tb9gt8weg7y9rnxrt6q1rbgicymzjnw6 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bBbbpZe0; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-HE-Tag: 1661372749-201316 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 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