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 9C704ECAAA2 for ; Thu, 25 Aug 2022 23:36:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF62E6B0074; Thu, 25 Aug 2022 19:36:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7EAF6B0075; Thu, 25 Aug 2022 19:36:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F8D0940007; Thu, 25 Aug 2022 19:36:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7B2856B0074 for ; Thu, 25 Aug 2022 19:36:25 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 48509804DD for ; Thu, 25 Aug 2022 23:36:25 +0000 (UTC) X-FDA: 79839726330.08.10CF239 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id E68B7C0009 for ; Thu, 25 Aug 2022 23:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661470583; 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=fZkbW2nKw9OcNR++w2Lt3hNVn3FfxAMwHGTXAs+/ztQ=; b=NVvv0j+l4lqJT/TDtvANtYh9/Ba/InC83JiOeGL6MfuRugbtj3E6solgKEn0iElUd9nsCN yi+iVAy1t6mnErRjOGks5hUBUCtXVu1Rs2nTVtIuTcQU9vnQG8a5gKjtwo+75WfOLKzb3B qOiH91wQpBpWWy6qk+L9oUUWfYimETE= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-612-Bgaxd-zVP-m0NUO0jYTkWw-1; Thu, 25 Aug 2022 19:36:22 -0400 X-MC-Unique: Bgaxd-zVP-m0NUO0jYTkWw-1 Received: by mail-qv1-f69.google.com with SMTP id k3-20020a05621414e300b00496e11f8d8aso8561376qvw.9 for ; Thu, 25 Aug 2022 16:36:22 -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=fZkbW2nKw9OcNR++w2Lt3hNVn3FfxAMwHGTXAs+/ztQ=; b=BSMcUSVoHeEsUvBP/Sfs442FizxCAyYm4OggRSI+/VytyDu9jI0I4zQcIKTQSVGZ8I ENMQURjLcbt7UAT6nq81AxMqOKVJeu2Gzxvz9KVThhGKr+Z9jZnie9+FwrZ/Aw6oVfH/ Fd1HBcoU4lcs8bnvIT/QyBMufuRg5t6Hni8snSjxvcgeMepsRFfOG4fAMghTbAcGe5mB RqRIlPDiJNyDBZS+JorDNLQm5QsCmaWrgERtcQ7fsR2Cfeh/6ykRl7zwcH0yC7+Cqlh/ 2qPkndIvS5qlycuChoOisgRBa/3wT3VKN2fxd8/Iup/Lesjw1D4Ak51puAYFw3qHrB/5 aQ1w== X-Gm-Message-State: ACgBeo1orJvDDY8B3XavRCQ5k2/6V2ApwgLtkBAR5crGF4wLpaE6lF7P 6pdm93wExubPA7CKWQLbO++VfEQM4vERpWQxh0i9S/rvewlU7/Y9CWXnO+clHIgDGNzmc6kdu/B LMMiXpypc+Fo= X-Received: by 2002:ac8:5948:0:b0:342:f500:2eb7 with SMTP id 8-20020ac85948000000b00342f5002eb7mr5760963qtz.483.1661470581830; Thu, 25 Aug 2022 16:36:21 -0700 (PDT) X-Google-Smtp-Source: AA6agR7TBH9R3amncjXP/5aFj5LeS8C1KlxU0maHmlQmU9GZdotjAyQBWdSKlYFKnk+U7FuoDJCUoA== X-Received: by 2002:ac8:5948:0:b0:342:f500:2eb7 with SMTP id 8-20020ac85948000000b00342f5002eb7mr5760938qtz.483.1661470581599; Thu, 25 Aug 2022 16:36:21 -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 w16-20020a05620a425000b006bba46e5eeasm663162qko.37.2022.08.25.16.36.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 16:36:21 -0700 (PDT) Date: Thu, 25 Aug 2022 19:36:18 -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: <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> <877d2wezll.fsf@nvdebian.thelocal> MIME-Version: 1.0 In-Reply-To: <877d2wezll.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=1661470584; a=rsa-sha256; cv=none; b=GTyVEyoqZPihQTCX6+Y28/Mk/7QqJh7K+YRuh8RsEzXfcYJY56g3qHnekCCi2trWkicmFw fsND3NXRIsWal6ODaVqzTV9Wwj+fNs7qt0GP0gT2lXxyfMJrGAPKhIdZsx6WhxnwVAUEi7 bkhk2v0u4EgdqJ7wdGN3mdIHz9IQ8xs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=NVvv0j+l; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661470584; 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=fZkbW2nKw9OcNR++w2Lt3hNVn3FfxAMwHGTXAs+/ztQ=; b=OwtFwvKJUTAVWViPfB71BmEdoJhFnz5+EF89u32+tAuUtF1Iq8gIFTQVHURiNmJI5P47Iw dwwDP7ojK8vaW42i5kFAhmJqTQ2Tf0ebeDb2SBcIazmCcD1rzTqHv/CfL4tLz4WS8OcwSw sweLb6Ay4hWrjHjKzfTcjfSm3sID4A4= Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=NVvv0j+l; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: n8qtefpfsra8y76ci1dxe819q933etfp X-Rspamd-Queue-Id: E68B7C0009 X-HE-Tag: 1661470583-593792 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 Fri, Aug 26, 2022 at 08:09:28AM +1000, Alistair Popple wrote: > > 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). > > Migration is always best effort. Callers need to be prepared to handle > failure of a particular page to migrate, but I could believe not all of > them are. Ok, I see that ppc list is in the loop, hopefully this issue is aware since afaict ppc will sigbus when migrate_vma_setup() fails, otoh the svm code just dumps some device error (and I didn't check upper the stack from there). > > > 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. > > You seem to have the point of it. The trylock_page() is to avoid > deadlock, and failure is always an option for migration. Drivers can > always retry if they really need the page to migrate, although success > is never guaranteed. For example the page might be pinned (or have > swap-cache allocated to it, but I'm hoping to at least get that fixed). If so I'd suggest even more straightforward document for either this trylock() or on the APIs (e.g. for migrate_vma_setup()). This behavior is IMHO hiding deep and many people may not realize. I'll comment in the comment update patch. Thanks. -- Peter Xu