From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE896E55A for ; Thu, 25 Sep 2025 01:43:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758764631; cv=none; b=nVbycjAK1vb48OW0+eoqF56i5xbg7vDA869l+zW5vAl24ZMXpvpMcJBhQJ3EaB+vpjZB2HLKOB5D0J8kqlSOi9633Trtsssh6OZtqPvEC65/4dMC/NlBGnY4RRcAivebnpjrdi6BpXCVusXX45qMOfo4A019yp+2vWLK97QW+Ss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758764631; c=relaxed/simple; bh=6fvEYqF7LhBRq+bdHhpoToXVlngkZX0IW+7BL676UUI=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=j3IcekLM7fWZBcyWy6rcBMGbs43PS6qAudDUWsKC1cE0JJQVxjrWEpQP1B9T0V61nsgff0Ije3UVoMgZFtoo5uE4uReSa460AL6gxBFWBKx+xgeK6KbTWyZ0O2XVAFQZWdGCedh9XKsn7U+d0w7w66n/NJ7vEEZ8BPgDbBq8qdg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4cXGb80jBLzddVk; Thu, 25 Sep 2025 09:39:00 +0800 (CST) Received: from kwepemr500001.china.huawei.com (unknown [7.202.194.229]) by mail.maildlp.com (Postfix) with ESMTPS id 2D3111401E9; Thu, 25 Sep 2025 09:43:39 +0800 (CST) Received: from [10.174.179.35] (10.174.179.35) by kwepemr500001.china.huawei.com (7.202.194.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 25 Sep 2025 09:43:37 +0800 Message-ID: <8313b0c1-bf62-4257-951c-fd7e29193ae2@huawei.com> Date: Thu, 25 Sep 2025 09:43:37 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 2/2] mm: add PMD-level huge page support for remap_pfn_range() To: David Hildenbrand , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , References: <20250923133104.926672-1-yintirui@huawei.com> <20250923133104.926672-3-yintirui@huawei.com> From: Yin Tirui In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemr500001.china.huawei.com (7.202.194.229) On 9/24/2025 5:50 PM, David Hildenbrand wrote: >> Introduce pfnmap_max_page_shift parameter to control maximum page >> size and "nohugepfnmap" boot option to disable huge pfnmap entirely. > > Why? If an arch supports it we should just do it. Or what's the reason > behind that? > There's no specific reason for this - it was just intended to provide an additional option. I'll remove it in the next version. ... > Are you sure we can just entirely remove this block for ! > vma_is_anonymous(vma)? > Thank you for pointing this out! There is definitely a problem with removing this block entirely for non-anonymous VMAs. I've also found some other problems. I'll fix all of them in the next version. -- Best regards, Yin Tirui