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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 8E174C55179 for ; Fri, 6 Nov 2020 20:56:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2358B20B1F for ; Fri, 6 Nov 2020 20:56:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="lbkHqjuG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728545AbgKFU4x (ORCPT ); Fri, 6 Nov 2020 15:56:53 -0500 Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:18697 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727559AbgKFU4w (ORCPT ); Fri, 6 Nov 2020 15:56:52 -0500 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Fri, 06 Nov 2020 12:56:56 -0800 Received: from rcampbell-dev.nvidia.com (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Nov 2020 20:56:47 +0000 Subject: Re: [PATCH v3 1/6] mm/thp: add prep_transhuge_device_private_page() To: Christoph Hellwig CC: , , , , "Jerome Glisse" , John Hubbard , "Alistair Popple" , Jason Gunthorpe , Bharata B Rao , Zi Yan , "Kirill A . Shutemov" , Yang Shi , Ben Skeggs , Shuah Khan , "Andrew Morton" References: <20201106005147.20113-1-rcampbell@nvidia.com> <20201106005147.20113-2-rcampbell@nvidia.com> <20201106075554.GA31341@lst.de> From: Ralph Campbell X-Nvconfidentiality: public Message-ID: Date: Fri, 6 Nov 2020 12:56:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20201106075554.GA31341@lst.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1604696216; bh=GkUJF2wcwNFtVtDfugtak/8XayWbGhH8zDvyol5BTOw=; h=Subject:To:CC:References:From:X-Nvconfidentiality:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=lbkHqjuGwbH6A6WGPayoyWp6kjVQqyl+1HlMHQmgnRCG7ImrV+QA3prCNDi0hcHWH 5pgzBx1Xdiu5ctXNK+U2GWo6yTLpp7AtFcK24oWgkl+tyshpzWKi3wj8nIybRWGRq2 vRu4YZvc9pShH8njactRwiAh/sEg82BOK8FELyMy+kNsdPDnon5t2NINVetSuGRljd L/lVTVqhiQ9zwL+4m/hesd8jxRBj9zubOwR/SkuakblzyCIaImrr+oUvIdccAr+kza /OQJ0ZnhXsT5Tg7g8aJFNe/0xgH5aKdy9g16stNGBndeYj4+WjornFrjd3asoPuc4z qcYOZNQNpXU9w== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/5/20 11:55 PM, Christoph Hellwig wrote: > On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote: >> +extern void prep_transhuge_device_private_page(struct page *page); > > No need for the extern. Right, I was just copying the style. Would you like to see a preparatory patch that removes extern for the other declarations in huge_mm.h? >> +static inline void prep_transhuge_device_private_page(struct page *page) >> +{ >> +} > > Is the code to call this even reachable if THP support is configured > out? If not just declaring it unconditionally and letting dead code > elimination do its job might be a tad cleaner. The HMM test driver depends on TRANSPARENT_HUGEPAGE but the nouveau SVM option doesn't and SVM is still useful if TRANSPARENT_HUGEPAGE is not configured. The problem with defining prep_transhuge_device_private_page() in huge_mm.h as a static inline function is that prep_compound_page() and prep_transhuge_page() would have to be EXPORT_SYMBOL_GPL which are currently mm internal only. The intent is to make this helper callable by separate device driver modules using struct pages created with memremap_pages(). >> +void prep_transhuge_device_private_page(struct page *page) > > I think a kerneldoc comment explaining what this function is useful for > would be helpful. That is a good idea. I'll add it to v4. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ralph Campbell Subject: Re: [PATCH v3 1/6] mm/thp: add prep_transhuge_device_private_page() Date: Fri, 6 Nov 2020 12:56:47 -0800 Message-ID: References: <20201106005147.20113-1-rcampbell@nvidia.com> <20201106005147.20113-2-rcampbell@nvidia.com> <20201106075554.GA31341@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20201106075554.GA31341@lst.de> Content-Language: en-US To: Christoph Hellwig Cc: linux-mm@kvack.org, nouveau@lists.freedesktop.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Jerome Glisse , John Hubbard , Alistair Popple , Jason Gunthorpe , Bharata B Rao , Zi Yan , "Kirill A . Shutemov" , Yang Shi , Ben Skeggs , Shuah Khan , Andrew Morton List-Id: nouveau.vger.kernel.org On 11/5/20 11:55 PM, Christoph Hellwig wrote: > On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote: >> +extern void prep_transhuge_device_private_page(struct page *page); > > No need for the extern. Right, I was just copying the style. Would you like to see a preparatory patch that removes extern for the other declarations in huge_mm.h? >> +static inline void prep_transhuge_device_private_page(struct page *page) >> +{ >> +} > > Is the code to call this even reachable if THP support is configured > out? If not just declaring it unconditionally and letting dead code > elimination do its job might be a tad cleaner. The HMM test driver depends on TRANSPARENT_HUGEPAGE but the nouveau SVM option doesn't and SVM is still useful if TRANSPARENT_HUGEPAGE is not configured. The problem with defining prep_transhuge_device_private_page() in huge_mm.h as a static inline function is that prep_compound_page() and prep_transhuge_page() would have to be EXPORT_SYMBOL_GPL which are currently mm internal only. The intent is to make this helper callable by separate device driver modules using struct pages created with memremap_pages(). >> +void prep_transhuge_device_private_page(struct page *page) > > I think a kerneldoc comment explaining what this function is useful for > would be helpful. That is a good idea. I'll add it to v4.