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=-0.6 required=3.0 tests=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 E3A81C47255 for ; Sat, 9 May 2020 03:17:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A8767217BA for ; Sat, 9 May 2020 03:17:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="mjzVRHGS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A8767217BA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4160890002F; Fri, 8 May 2020 23:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 378FD90001C; Fri, 8 May 2020 23:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F30C90002F; Fri, 8 May 2020 23:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 0604790001C for ; Fri, 8 May 2020 23:17:37 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B54B64410 for ; Sat, 9 May 2020 03:17:36 +0000 (UTC) X-FDA: 76795720512.20.brass67_2547caeac9621 X-HE-Tag: brass67_2547caeac9621 X-Filterd-Recvd-Size: 3881 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Sat, 9 May 2020 03:17:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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=lyg8KFPxTn0tWshWc1x4r9ezlzCrdRUk1alOb1U8QOk=; b=mjzVRHGSFUzWCtzv5ct3WCVzIJ ctNdyru+3tw2Jx6byTHTJQdaLOT6wypRAwM0vM2BA4uTaZtqgBMteST/YjZJAGCjBwcYThXJPE7/x yKqdUpYrah7TLL+CgNUvGMi7er7Ds8YVx/LcngEtraSyPD7EPowngkYGh2oEmoNlgi8apHTbQjn/V buoEqQ4HLNZNOjPcy+7VUaM1SwZI2P+rqXh0qrcN0izk711h14xjyY8hAK7g2BXziyMosb87vaZUW IzKvDkrSzkQsUUdLQZC3Zpq8nEMRjyBLe+cpQChBogC+1GMjV2EmiLtnG0vtSzWy/cSY+ZO6ik0mL /JrDhQLw==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jXFzS-0001xm-Dk; Sat, 09 May 2020 03:17:26 +0000 Date: Fri, 8 May 2020 20:17:26 -0700 From: Matthew Wilcox To: Ralph Campbell Cc: nouveau@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Jerome Glisse , John Hubbard , Christoph Hellwig , Jason Gunthorpe , Ben Skeggs , Andrew Morton , Shuah Khan Subject: Re: [PATCH 0/6] nouveau/hmm: add support for mapping large pages Message-ID: <20200509031726.GT16070@bombadil.infradead.org> References: <20200508192009.15302-1-rcampbell@nvidia.com> <20200508195910.GR16070@bombadil.infradead.org> <72422dca-e025-002a-4748-addfb392ffc4@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72422dca-e025-002a-4748-addfb392ffc4@nvidia.com> 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, May 08, 2020 at 01:17:55PM -0700, Ralph Campbell wrote: > On 5/8/20 12:59 PM, Matthew Wilcox wrote: > > On Fri, May 08, 2020 at 12:20:03PM -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 the page is mapped > > > using a larger page size. To be fully general, hmm_range_fault() would need > > > to return the mapping size to handle cases like a 1GB compound page being > > > mapped with 2MB PMD entries. However, the most common case is the mapping > > > size the same as the underlying compound page size. > > > This series adds a new output flag to indicate this so that callers know it > > > is safe to use a large device page table mapping if one is available. > > > Nouveau and the HMM tests are updated to use the new flag. > > > > This explanation doesn't make any sense. It doesn't matter how somebody > > else has it mapped; if it's a PMD-sized page, you can map it with a > > 2MB mapping. > > Sure, the I/O will work OK, but is it safe? > Copy on write isn't an issue? splitting a PMD in one process due to > mprotect of a shared page will cause other process' page tables to be split > the same way? Are you saying that if you call this function on an address range of a process which has done COW of a single page in the middle of a THP, you want to return with this flag clear, but if the THP is still intact, you want to set this flag? > Recall that these are system memory pages that could be THPs, shmem, hugetlbfs, > mmap shared file pages, etc.