Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.117.160 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.117.160; helo=mail.nvidia.com; pr=C
Message-ID: <92965844-c430-8b8e-d9f1-705d7578bceb@nvidia.com>
Date:   Wed, 7 Dec 2022 16:38:22 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.1
Subject: Re: [PATCH mm-unstable] mm: clarify folio_set_compound_order() zero
 support
Content-Language: en-US
To:     Sidhartha Kumar <sidhartha.kumar@oracle.com>,
        <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
CC:     <akpm@linux-foundation.org>, <songmuchun@bytedance.com>,
        <mike.kravetz@oracle.com>, <willy@infradead.org>,
        <tsahu@linux.ibm.com>, <david@redhat.com>
References: <20221207223731.32784-1-sidhartha.kumar@oracle.com>
From:   John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <20221207223731.32784-1-sidhartha.kumar@oracle.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2022 00:38:32.3452
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cb35c5af-c518-4bec-3072-08dad8b488a2
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.160];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT089.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6575
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,
        SPF_NONE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 12/7/22 14:37, Sidhartha Kumar wrote:
> Document hugetlb's use of a zero compound order so support for zero
> orders is not removed from folio_set_compound_order().
> 
> Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
> Suggested-by: Mike Kravetz <mike.kravetz@oracle.com>
> Suggested-by: Muchun Song <songmuchun@bytedance.com>
> ---
> This can be folded into f2b67a51d0ef6871d4fb0c3e8199f278112bd108
> mm: add folio dtor and order setter functions
> 
>   include/linux/mm.h | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 443d496949a8..cd8508d728f1 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -999,9 +999,16 @@ static inline void set_compound_order(struct page *page, unsigned int order)
>   #endif
>   }
>   
> +/*
> + * folio_set_compound_order is generally passed a non-zero order to
> + * initialize a large folio.  However, hugetlb code abuses this by
> + * passing in zero when 'dissolving' a large folio.
> + */

Wouldn't it be better to instead just create a new function for that
case, such as:

     dissolve_large_folio()

?

>   static inline void folio_set_compound_order(struct folio *folio,
>   		unsigned int order)
>   {
> +	VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
> +
>   	folio->_folio_order = order;
>   #ifdef CONFIG_64BIT
>   	folio->_folio_nr_pages = order ? 1U << order : 0;

thanks,
-- 
John Hubbard
NVIDIA