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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 62C02C433C1 for ; Wed, 24 Mar 2021 15:50:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF74E61A0D for ; Wed, 24 Mar 2021 15:50:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF74E61A0D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4FA1D6B02DD; Wed, 24 Mar 2021 11:50:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A9AE6B02DF; Wed, 24 Mar 2021 11:50:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 323346B02E0; Wed, 24 Mar 2021 11:50:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0090.hostedemail.com [216.40.44.90]) by kanga.kvack.org (Postfix) with ESMTP id 18AEE6B02DD for ; Wed, 24 Mar 2021 11:50:33 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D06FA18360DC2 for ; Wed, 24 Mar 2021 15:50:32 +0000 (UTC) X-FDA: 77955205104.15.D5897FE Received: from pio-pvt-msa2.bahnhof.se (pio-pvt-msa2.bahnhof.se [79.136.2.41]) by imf13.hostedemail.com (Postfix) with ESMTP id 6DE10E007A54 for ; Wed, 24 Mar 2021 15:50:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTP id 19BC23F4C3; Wed, 24 Mar 2021 16:50:10 +0100 (CET) Authentication-Results: pio-pvt-msa2.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=P4M4/6D1; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from pio-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu7IkG0scZsZ; Wed, 24 Mar 2021 16:50:09 +0100 (CET) Received: by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 1D9B73F4C0; Wed, 24 Mar 2021 16:50:07 +0100 (CET) Received: from [10.249.254.166] (unknown [192.198.151.44]) by mail1.shipmail.org (Postfix) with ESMTPSA id BEC513605CC; Wed, 24 Mar 2021 16:50:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1616601017; bh=LVYFmsFXj0e1zpHSjkB8DcFvTKZT5BbydC++etvHV1o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P4M4/6D1LgeNspLbb2o1Hp54DiW0ZNauP1DTjhNR3h+MUyHSzrWyvMYSi1sIGu+er R2R+O2pCd3UrThkwmu/7GYJhshjSIt+My1In3wYMF5pgI/WTEkbOv27oayzhL5GGIv ltOwfYUHBp3R1b3g9VhVSeW2Cd+h0VLlXj7AHJ/w= Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages To: Jason Gunthorpe Cc: David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Andrew Morton , Christian Koenig References: <20210321184529.59006-2-thomas_os@shipmail.org> <314fc020-d243-dbf0-acb3-ecfcc9c2443c@shipmail.org> <20210323163715.GJ2356281@nvidia.com> <5824b731-ca6a-92fd-e314-d986b6a7b101@shipmail.org> <20210324122430.GW2356281@nvidia.com> <20210324124127.GY2356281@nvidia.com> <6c9acb90-8e91-d8af-7abd-e762d9a901aa@shipmail.org> <20210324134833.GE2356281@nvidia.com> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: <0b984f96-00fb-5410-bb16-02e12b2cc024@shipmail.org> Date: Wed, 24 Mar 2021 16:50:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210324134833.GE2356281@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Stat-Signature: zoo14b4sfkwksticox51m8r1j8e9ys4y X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6DE10E007A54 Received-SPF: none (shipmail.org>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=pio-pvt-msa2.bahnhof.se; client-ip=79.136.2.41 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616601021-60786 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 3/24/21 2:48 PM, Jason Gunthorpe wrote: > On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellstr=C3=B6m (Intel)= wrote: > >>> In an ideal world the creation/destruction of page table levels would >>> by dynamic at this point, like THP. >> Hmm, but I'm not sure what problem we're trying to solve by changing t= he >> interface in this way? > We are trying to make a sensible driver API to deal with huge pages. > =20 >> Currently if the core vm requests a huge pud, we give it one, and if w= e >> can't or don't want to (because of dirty-tracking, for example, which = is >> always done on 4K page-level) we just return VM_FAULT_FALLBACK, and th= e >> fault is retried at a lower level. > Well, my thought would be to move the pte related stuff into > vmf_insert_range instead of recursing back via VM_FAULT_FALLBACK. > > I don't know if the locking works out, but it feels cleaner that the > driver tells the vmf how big a page it can stuff in, not the vm > telling the driver to stuff in a certain size page which it might not > want to do. > > Some devices want to work on a in-between page size like 64k so they > can't form 2M pages but they can stuff 64k of 4K pages in a batch on > every fault. Hmm, yes, but we would in that case be limited anyway to insert ranges=20 smaller than and equal to the fault size to avoid extensive and possibly=20 unnecessary checks for contigous memory. And then if we can't support=20 the full fault size, we'd need to either presume a size and alignment of=20 the next level or search for contigous memory in both directions around=20 the fault address, perhaps unnecessarily as well. I do think the current=20 interface works ok, as we're just acting on what the core vm tells us to = do. /Thomas > > That idea doesn't fit naturally if the VM is driving the size. > > Jason