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 33814C32774 for ; Thu, 25 Aug 2022 15:05:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81428940007; Thu, 25 Aug 2022 11:05:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79D7F6B0074; Thu, 25 Aug 2022 11:05:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6164C940007; Thu, 25 Aug 2022 11:05:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4D08D6B0073 for ; Thu, 25 Aug 2022 11:05:07 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 27A2A1403BD for ; Thu, 25 Aug 2022 15:05:07 +0000 (UTC) X-FDA: 79838437854.06.9C6B9FA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 3045240012 for ; Thu, 25 Aug 2022 15:05:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661439905; 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=iygQAkAgz4JDbn3KVJAwromqSNqOkmZrJ35R+TSCGBw=; b=WbSg80lyvUQyENVdiNOFKKUNKeYOjb0cQAJn7tdJYmuQwBr4HYb7HCokp59/SE1IBBP4eH 8cjpOEWd6amp0/cVC3DySSecEallveOSCz9A9dwz4XGBkui0ufuIKD562xAdywxDuTppQE d1EXedFasT5ttOZrLykSAwZ8MhEc2aY= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-653-oqrkMdCPPv6RKZ2W2ZqOVg-1; Thu, 25 Aug 2022 11:05:03 -0400 X-MC-Unique: oqrkMdCPPv6RKZ2W2ZqOVg-1 Received: by mail-qk1-f198.google.com with SMTP id u15-20020a05620a0c4f00b006b8b3f41303so17314387qki.8 for ; Thu, 25 Aug 2022 08:05:03 -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=iygQAkAgz4JDbn3KVJAwromqSNqOkmZrJ35R+TSCGBw=; b=2dVUcxdV217PfcaMKoJUx4vQkm4/otQMlbrGl0vTmKGfWMxYiXRetAagd8mVnq7IAK pEDdMOJiOsw7dGIGo4+jxFPESlfeycOcdhC8cKQskXuNuXpEeIzS4K2wQALDe9yoRPsD unc4H/DM6N4eTVAwVj2lpftGvJXGMr+RHC9ALfvfaqRaZ4zsj/gFSy2dhW+pdzuD1AR+ DKpak3Fx2d1XcYoZv1O5tlMH2VVKzXIZPoC35dWLVsZrxKICzg5S81LEnqZcuOjZ7z/+ uvUKuemW+9YE06Q8+zlMdr4fTCQ7Ut+Gqf4U9U5YcCuq+Uo4rY7YqVVevV9yIR1nAoIU y/3w== X-Gm-Message-State: ACgBeo3IEFpb3kDb4bOKHNzK0MygeitGxbBTEEyu1pIYQ/50x8r8dX5C Q8yqv4HYvpqgpD3gYhLV5QwdbuzKxCFns5KRPlKxWJLv07iohqaET3LnWDz6AxRw7G0hBYaOFJi HM5dIaWltxdU= X-Received: by 2002:a05:622a:20e:b0:343:7345:36cc with SMTP id b14-20020a05622a020e00b00343734536ccmr3971318qtx.669.1661439903393; Thu, 25 Aug 2022 08:05:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR5H6vUeaILfaettSLPx9OGO+p9IBfx7a4trs9PcWFxW10+WU/QvLs3nwiKRw0dOgxGyx6Uy1A== X-Received: by 2002:a05:622a:20e:b0:343:7345:36cc with SMTP id b14-20020a05622a020e00b00343734536ccmr3971288qtx.669.1661439903064; Thu, 25 Aug 2022 08:05:03 -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 bm25-20020a05620a199900b006b949afa980sm17692978qkb.56.2022.08.25.08.04.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 08:05:01 -0700 (PDT) Date: Thu, 25 Aug 2022 11:04:59 -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: <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> <87o7w9f7dp.fsf@nvdebian.thelocal> <87k06xf70l.fsf@nvdebian.thelocal> MIME-Version: 1.0 In-Reply-To: <87k06xf70l.fsf@nvdebian.thelocal> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661439906; 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=iygQAkAgz4JDbn3KVJAwromqSNqOkmZrJ35R+TSCGBw=; b=6d5WvDe3cE9iPd+YDCejOETvKeZkv2uLM+GvRHk9dC7Wfv4R0CpvrmwWIGHlRrWbnvEn2k WH7C8/OfQQazB8b5mOTAVgYahQY+AUcxMWd4D3ovjEYeBqNz3Ib6H1cmfMKEMMPRlAOdql HuB3mL3xOH/LkyQOO2PfIyswaWjis/Y= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WbSg80ly; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf12.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661439906; a=rsa-sha256; cv=none; b=hWiEind6EiNhltc1h5O81o66ooFmozaXG9pL1Mc28Cmz4QqNCFFI1ZiRJO1Qx2hF+dumRA VEyVsAuS7ltA+Gz/MEvbS/Ff5Z8L7H3eaC3doPSK9R7ByDeSI+dOtHOewrBW6wMewqzv0a F+voqelkSjBAA5djzTa9t2HTqv/ChTs= Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WbSg80ly; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf12.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Queue-Id: 3045240012 X-Rspamd-Server: rspam10 X-Stat-Signature: gzz4uqby1pcuogspx9rpdz5ac1uusdcz X-HE-Tag: 1661439905-270478 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 Thu, Aug 25, 2022 at 11:24:03AM +1000, Alistair Popple wrote: > By the way it's still an optimisation because in most cases we can avoid > calling try_to_migrate() and walking the rmap altogether if we install > the migration entries here. But I agree the comment is misleading. There's one follow up question I forgot to ask on the trylock thing. I figured maybe I should ask out loud since we're at it. Since migrate_vma_setup() always only use trylock (even if before dropping the prepare() code), does it mean that it can randomly fail? I looked at some of the callers, it seems not all of them are ready to handle that (__kvmppc_svm_page_out() or svm_migrate_vma_to_vram()). Is it safe? Do the callers need to always properly handle that (unless the migration is only a best-effort, but it seems not always the case). Besides, since I read the old code of prepare(), I saw this comment: - if (!(migrate->src[i] & MIGRATE_PFN_LOCKED)) { - /* - * Because we are migrating several pages there can be - * a deadlock between 2 concurrent migration where each - * are waiting on each other page lock. - * - * Make migrate_vma() a best effort thing and backoff - * for any page we can not lock right away. - */ - if (!trylock_page(page)) { - migrate->src[i] = 0; - migrate->cpages--; - put_page(page); - continue; - } - remap = false; - migrate->src[i] |= MIGRATE_PFN_LOCKED; - } I'm a bit curious whether that deadlock mentioned in the comment is observed in reality? If the page was scanned in the same address space, logically the lock order should be guaranteed (if both page A&B, both threads should lock in order). I think the order can be changed if explicitly did so (e.g. fork() plus mremap() for anonymous here) but I just want to make sure I get the whole point of it. Thanks, -- Peter Xu