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 X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EC8CC43460 for ; Tue, 18 May 2021 18:01:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 95E4760724 for ; Tue, 18 May 2021 18:01:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95E4760724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CFA686B0150; Tue, 18 May 2021 14:01:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD1546B0151; Tue, 18 May 2021 14:01:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFD246B0152; Tue, 18 May 2021 14:01:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 7D22A6B0150 for ; Tue, 18 May 2021 14:01:42 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 24E72181AF5F7 for ; Tue, 18 May 2021 18:01:42 +0000 (UTC) X-FDA: 78155119644.34.93D653B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 521A5C001C68 for ; Tue, 18 May 2021 18:01:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621360901; 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=Oue7U1wjftn7xVwPmUZCJccBeCJY9jE5A9d8yc2+hO4=; b=Ora0ec0MtMLAuvk+SbeTaOUni3CLwx59zVFX5AqLzUlof5EBxe0IA8CZNvO17Q+uDbisd0 FgtwJ9J3KXftksjHr0Rdrigywaka5q7oWMySvpVP28sE+X2eFqtF78oLGJQuZcJQ7DrQTk M8APNkPboCNwMbRfLfAbVDrK6NqsCJk= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-263-foXq0q7DMDq6Eih4tBYQ7w-1; Tue, 18 May 2021 14:01:39 -0400 X-MC-Unique: foXq0q7DMDq6Eih4tBYQ7w-1 Received: by mail-qv1-f69.google.com with SMTP id w4-20020a0c8e440000b02901f0640ffdafso3138168qvb.13 for ; Tue, 18 May 2021 11:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Oue7U1wjftn7xVwPmUZCJccBeCJY9jE5A9d8yc2+hO4=; b=BXDjS511GQRKimDhaZKDwfej1mzvplMKLYfDzOKJB1nyDS5/zPJ0C3t1FBCYsVT4HX hTda8bv+rB4adxmXzuUUfO6UMJsawPepabfUqRfRIPsstHUqNmMRV5lCnTdJafgE14mw D1gceMMWxeEXVTgovKlLnh5wYncGH3yyRFwqoYzZEAo/lly+pPLuGFnvy5mq4jkkXcsq 4XEHyyf4sTzGuj1m3Aniu0/HAKPmJGE0XgjRrGheDA6e5XlJ9ae5YcfS3k/L15M8H+r8 GnDGs42psGmdgqeVc9i1pWlecs9zokrtQvLsUGlcLOZPpJUupuJ+4MRSWl8DKFMYb2LG /cxA== X-Gm-Message-State: AOAM530oZIYlqJo36E+Xl0s1aBZs8hvPnkpfyyK8ZT6m6c8Khw4u1KpO SmA50O2NZO0os6/+Y3t/IfQVstPOMjK1gIT9Ia7jCUvuy6WFp/SOT9/faP/v89z7FT/3cvhZlJQ 3wmV+Frqgocg= X-Received: by 2002:ac8:a49:: with SMTP id f9mr6060399qti.157.1621360898459; Tue, 18 May 2021 11:01:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTICgj8/egwsE0Ivgqvw8kGv1T8HxyWhbScHPLgGtw0FYHBEe8vymzLu/hxY0OnGRaALaW5w== X-Received: by 2002:ac8:a49:: with SMTP id f9mr6060354qti.157.1621360898147; Tue, 18 May 2021 11:01:38 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id b23sm1488671qtp.7.2021.05.18.11.01.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 May 2021 11:01:37 -0700 (PDT) Date: Tue, 18 May 2021 14:01:36 -0400 From: Peter Xu To: Jason Gunthorpe Cc: Alistair Popple , linux-mm@kvack.org, nouveau@lists.freedesktop.org, bskeggs@redhat.com, akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, jhubbard@nvidia.com, rcampbell@nvidia.com, jglisse@redhat.com, hch@infradead.org, daniel@ffwll.ch, willy@infradead.org, bsingharora@gmail.com, Christoph Hellwig Subject: Re: [PATCH v8 5/8] mm: Device exclusive memory access Message-ID: References: <20210407084238.20443-1-apopple@nvidia.com> <20210407084238.20443-6-apopple@nvidia.com> <47694715.suB6H4Uo8R@nvdebian> <20210518173334.GE1002214@nvidia.com> MIME-Version: 1.0 In-Reply-To: <20210518173334.GE1002214@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ora0ec0M; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf03.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com X-Stat-Signature: su7hxnpnqgzyoe63d3tgxu5i1dr1gud7 X-Rspamd-Queue-Id: 521A5C001C68 X-Rspamd-Server: rspam02 X-HE-Tag: 1621360900-999362 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, May 18, 2021 at 02:33:34PM -0300, Jason Gunthorpe wrote: > On Tue, May 18, 2021 at 01:27:42PM -0400, Peter Xu wrote: > > > I also have a pure and high level question regarding a process fork() when > > there're device exclusive ptes: would the two processes then own the device > > together? Is this a real usecase? > > If the pages are MAP_SHARED then yes. All VMAs should point at the > same device_exclusive page and all VMA should migrate back to CPU > pages together. Makes sense. If we keep the anonymous-only in this series (I think it's good to separate these), maybe we can drop the !COW case, plus some proper installed WARN_ON_ONCE()s. > > > Indeed it'll be odd for a COW page since for COW page then it means after > > parent/child writting to the page it'll clone into two, then it's a mistery on > > which one will be the one that "exclusived owned" by the device.. > > For COW pages it is like every other fork case.. We can't reliably > write-protect the device_exclusive page during fork so we must copy it > at fork time. > > Thus three reasonable choices: > - Copy to a new CPU page > - Migrate back to a CPU page and write protect it > - Copy to a new device exclusive page IMHO the ownership question would really help us to answer this one.. If the device ownership should be kept in parent IMHO option (1) is the best approach. To be explicit on page copy: we can do best-effort, even if the copy is during a device atomic operation, perhaps? If the ownership will be shared, seems option (3) will be easier as I don't see a strong reason to do immediate restorinng of ptes; as long as we're careful on the refcounting. Thanks, -- Peter Xu