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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 38C72C433E0 for ; Thu, 14 Jan 2021 02:35:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C9D423600 for ; Thu, 14 Jan 2021 02:35:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C9D423600 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 134536B01B3; Wed, 13 Jan 2021 21:35:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0ED056B01F0; Wed, 13 Jan 2021 21:35:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC5376B01F1; Wed, 13 Jan 2021 21:35:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id D178E6B01B3 for ; Wed, 13 Jan 2021 21:35:50 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9F32A180AD81D for ; Thu, 14 Jan 2021 02:35:50 +0000 (UTC) X-FDA: 77702815260.30.hose24_3117b1f27523 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 7C1C7180B3C85 for ; Thu, 14 Jan 2021 02:35:50 +0000 (UTC) X-HE-Tag: hose24_3117b1f27523 X-Filterd-Recvd-Size: 4590 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 02:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610591749; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2mud6EOiQWTPZLSAaAQAKID8YRfEwmVBCdj5DWD16lE=; b=LLeX7Yj/6c+X+liywIL+uphzG/UdkNpIcCwEVSeZ/LApXCkIIYTQU0kr3ybDvcEekrFuqK Dhwlc3v2XwFWH9MfGK/V0Ts7GjtCcJwXL2DgT1hj3Jzzz37bgSaMInkAtatVHYOY3InJJO IQnfw9XkRTyn7NlrlvOyBTJ+xhjSNkM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-544-IOSZym_oN-CrdgfWwCkC-Q-1; Wed, 13 Jan 2021 21:35:45 -0500 X-MC-Unique: IOSZym_oN-CrdgfWwCkC-Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0C08FE758; Thu, 14 Jan 2021 02:35:42 +0000 (UTC) Received: from redhat.com (ovpn-112-31.rdu2.redhat.com [10.10.112.31]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E5ADE1001B2C; Thu, 14 Jan 2021 02:35:32 +0000 (UTC) Date: Wed, 13 Jan 2021 21:35:30 -0500 From: Jerome Glisse To: Jason Gunthorpe Cc: Andrea Arcangeli , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yu Zhao , Andy Lutomirski , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Peter Zijlstra , Linus Torvalds , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Oleg Nesterov , Jann Horn , Kees Cook , John Hubbard , Leon Romanovsky , Jan Kara , Kirill Tkhai Subject: Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy Message-ID: <20210114023530.GB535630@redhat.com> References: <20210107200402.31095-1-aarcange@redhat.com> <20210107202525.GD504133@ziepe.ca> <20210108133649.GE504133@ziepe.ca> <20210108181945.GF504133@ziepe.ca> <20210109004255.GG504133@ziepe.ca> <20210113215638.GA528828@redhat.com> <20210113233936.GE4605@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20210113233936.GE4605@ziepe.ca> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable 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, Jan 13, 2021 at 07:39:36PM -0400, Jason Gunthorpe wrote: > On Wed, Jan 13, 2021 at 04:56:38PM -0500, Jerome Glisse wrote: >=20 > > is a broken model and the way GPU use GUP is less broken then RDMA. I= n > > GPU driver GUP contract with userspace is that the data the GPU can > > access is a snapshot of what the process memory was at the time you > > asked for the GUP. Process can start using different pages right afte= r. > > There is no constant coherency contract (ie CPU and GPU can be workin= g > > on different pages). >=20 > Look at the habana labs "totally not a GPU" driver, it doesn't work > that way, GPU compute operations do want coherency. >=20 > The mmu notifier hackery some of the other GPU drivers use to get > coherency requires putting the kernel between every single work > submission, and has all kinds of wonky issues and limitations - I > think it is net worse approach than GUP, honestly. Yes what GPU driver do today with GUP is wrong but it is only use for texture upload/download. So that is a very limited scope (amdkfd being an exception here). Yes also to the fact that waiting on GPU fence from mmu notifier callback is bad. We are thinking on how to solve this. But what do matter is that hardware is moving in right direction and we will no longer need GUP. So GUP is dying out in GPU driver. Cheers, J=E9r=F4me