Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp73590ybt; Tue, 30 Jun 2020 15:07:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzpCCKj+veRuPfqpJLEV5me31awpwAFc9+LMnr7YSERe/C9lUAlkba0LVXz0N72zr8QBZb X-Received: by 2002:aa7:d0d1:: with SMTP id u17mr24604518edo.13.1593554396391; Tue, 30 Jun 2020 14:59:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593554396; cv=none; d=google.com; s=arc-20160816; b=fxczk/3HzHnEFyVxtl2D0W++wYrr2joZolfusXgfPOmTUzHBBRU7PtOndlwVULiy8v xllV7Df8WFh16wHOnUSCDCfyzqk60Af4ejwGq2DrNictWBFD0X166M78zn+QEaMo14yy k1tH+niZffYmIV4ym09OQOooMYyW0hLeonahHxfDl8I9VfF4M1K0R5/0i0nhN56Y1lFZ EM4wrjHFZyXb/ywHoZr34ZZefC10MHIDXIkx341IIyssznpyIP/3JWIbk+25EetCW1b/ NcxRTngFkWH6xqDRn8gWQzutUFViHQwakX2uUjyWuMTbBj5aB120UUfMOjshNabb0tJ4 baVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=n8SHJfzy7p8PW3wOzwIG1BQWiEf6w6qyoS+BP0Vtvzc=; b=UfDJmtX2x1CB1ISzNxgjmV+SzD4hcDM4pCDBbmR/ldC4Ihqe/5qva9gN2FgMZWufwN Q+o0bj8H9MoZM1h1oXjeO/ey6+c34s2L50R+i8QiLh2KfSwzT5xnE7YP7KzBMaSk+vw4 Vg6MSq/9Ub4kWdJu4IXagHnynZ0Vg5FeHyTlfT+OE4AKYrt+7IkzSv0HOGMEwsjffofo CAAmqUiFJdlczh+AQ2zMdSH9WuQqXONZjUkD3qT39Si8Qu17SNbcdgSgLkEV//a4QkHh Klb8UurPAW54zEEIvvic3MMqmxLLM6FHSr9JHvWUcmN+uyPQ9WCQhtbOMdInBTc95WuG /5yA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=CWOPBHTb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b22si2753639edn.212.2020.06.30.14.59.33; Tue, 30 Jun 2020 14:59:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=CWOPBHTb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728574AbgF3VXr (ORCPT + 99 others); Tue, 30 Jun 2020 17:23:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725805AbgF3VXq (ORCPT ); Tue, 30 Jun 2020 17:23:46 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F7FAC061755; Tue, 30 Jun 2020 14:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=n8SHJfzy7p8PW3wOzwIG1BQWiEf6w6qyoS+BP0Vtvzc=; b=CWOPBHTbbV7jN6/0NnoGwn1IDU /8KBtqnWiJHtbzZnkwChwmYJjDAb2XDLufpU89h7mqwO7TlRcjxxI6rjcpTKLMx6q0Ff7L2fgDHmO DRsSGKj2b5iviSdaZSUjHgmK6nzwT7QXmpDPtFAA/CgPqJpNdmN5cJZhkbGZtrfYyBUuRpPE6pQ/D fhrlZYuY5B3JC8jSeH9oPEyVT7vUzZwwZOItAp00BZLjBSCipFKj1lWvQoNNkHIIbc/nmOp3Uh4fm AgPWvtO+pb0HLSss5V8jEjJebl1GuZvzjDkD8LqeTRHug9r51lYFKveyh+de9kE2sdRSrg8bliJHF wAIENPMQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqNjD-00007m-C1; Tue, 30 Jun 2020 21:23:43 +0000 Date: Tue, 30 Jun 2020 22:23:43 +0100 From: Matthew Wilcox To: Ralph Campbell Cc: linux-rdma@vger.kernel.org, linux-mm@kvack.org, nouveau@lists.freedesktop.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Jerome Glisse , John Hubbard , Christoph Hellwig , Jason Gunthorpe , Andrew Morton , Shuah Khan , Ben Skeggs Subject: Re: [PATCH v2 2/5] mm/hmm: add output flags for PMD/PUD page mapping Message-ID: <20200630212343.GP25523@casper.infradead.org> References: <20200630195737.8667-1-rcampbell@nvidia.com> <20200630195737.8667-3-rcampbell@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200630195737.8667-3-rcampbell@nvidia.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 30, 2020 at 12:57:34PM -0700, Ralph Campbell wrote: > hmm_range_fault() returns an array of page frame numbers and flags for > how the pages are mapped in the requested process' page tables. The PFN > can be used to get the struct page with hmm_pfn_to_page() and the page > size order can be determined with compound_order(page) but if the page > is larger than order 0 (PAGE_SIZE), there is no indication that a > compound page is mapped by the CPU using a larger page size. Without > this information, the caller can't safely use a large device PTE to map > the compound page because the CPU might be using smaller PTEs with > different read/write permissions. > > Add two new output flags to indicate the mapping size (PMD or PUD sized) > so that callers know the pages are being mapped with consistent permissions > and a large device page table mapping can be used if one is available. The problem I have with this is that PTE/PMD/PUD are not the only choices for how the CPU might choose to map something. For example, ARM has the ability to map 64kB pages using 16 consecutive page table entries (marked specially so the CPU knows to use a single TLB entry for the 64kB range). Some other CPUs have similar capabilities. I'd rather you encoded the order of the mapping in the flags (eg a number between 0 and 31) so that we have the flexibility in the future to describe how memory is mapped.