Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <3029924e-0857-3684-52ea-f37e924ceb4a@oracle.com>
Date:   Tue, 31 May 2022 09:56:52 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [RFC PATCH 1/3] hugetlb: skip to end of PT page mapping when pte
 not present
Content-Language: en-US
To:     Baolin Wang <baolin.wang@linux.alibaba.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc:     Muchun Song <songmuchun@bytedance.com>,
        Michal Hocko <mhocko@suse.com>, Peter Xu <peterx@redhat.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        James Houghton <jthoughton@google.com>,
        Mina Almasry <almasrymina@google.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>
References: <20220527225849.284839-1-mike.kravetz@oracle.com>
 <20220527225849.284839-2-mike.kravetz@oracle.com>
 <437e45c5-c46a-46f4-f9cf-d8c2397c988d@linux.alibaba.com>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <437e45c5-c46a-46f4-f9cf-d8c2397c988d@linux.alibaba.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UmR2ZGpqRzNURm92WWU3eGtTZ0FNTm4rekVrZUptVDVCeFVvRDRacEpWMEdF?=
 =?utf-8?B?MlljMUJPcXRyRnNDZ25VSGUrZjE3eDNhVW9oZktEUDVtUUVHU210V0hNK0FU?=
 =?utf-8?B?YWYycm5QZDZLbEVDcm5ZK3lHTXFGZWUxcnpqS3ZGb3JkMW91aEhQMERYS29C?=
 =?utf-8?B?RlVVQU5WNHcxK293eElmblNNTUNpNWM3cnpmS0tLVkU3aWZjM1Qwc3dxUFJG?=
 =?utf-8?B?dmlNSEFUZUJ2S1lYQkdWYmtEazBNUWtzZjBzWHRna0wvbVZKQzJzNTFuK0pw?=
 =?utf-8?B?cTVJQWd0WXVUaENrVlJjN013eGpmWXFGYW5vdTlWTXNhcm1qekh1WnpjdUJ2?=
 =?utf-8?B?a3E5UU0rYnhaUlpOYUw0ejI5VzZXbVk1bE1aa3dKbVpPNVFzZFpFdzUyV3N2?=
 =?utf-8?B?c0ZxRmh0K1RwOVg0cHh5LzlHak9YRWh6aGxuRmlJYXpBNnZwU25uTXdQbWJi?=
 =?utf-8?B?REJGU09wNDR0a1ZaMzBVZ2RzQjlUY0VpMTAreVdveHc4bk1CRFhPeFpWZkVu?=
 =?utf-8?B?SEhUa0FkS2dsKzh2d1czc3J0ekNEeVo4MnpzdE5YaUJDRm9rNWVPTThTd0Nu?=
 =?utf-8?B?bzh5WDRxRGxvZW5EU2VhV3A0LzJLbWtOWjV6RDU5MXd5QkFobi9iUGJqeFNY?=
 =?utf-8?B?RXIyRWZPbmgrb1UxN2ZVei81aFFpN0tEU01xd2h3N0VOcm42OU9GZWxiRnk0?=
 =?utf-8?B?bWl0cU9UUDFWbFlTTlJjV1RXc243a0t3MDRYZTZNVDNBSnUwV2FpRVdaZGhi?=
 =?utf-8?B?UkJ3RDI5Q0tnNFF0UFV2NDRaVE9TeG1wUTZsbEV1UDdTRm9CYmU0bE1YdTBh?=
 =?utf-8?B?M3FUcGR3bThBUzR0UnNBd2s4MHgyZGIySmNXUExiK1c2RVZtUFE0TWZpVWxh?=
 =?utf-8?B?WElUQldQdHM0VktrRURzSE1FOXdFMS9semkxNExpUDdJR1FMbEU0Yy91OXJE?=
 =?utf-8?B?SGhzSDdyY2ZxdFNrRzRuS0NyVkVNa1Vvd3RZOU53b0VyeitUbzlvYktuUUNt?=
 =?utf-8?B?NmtKMWwwejJGWThBZUlxOUNWYmVpaEhOekFrSzJhSE5QODdidlRLVC9MRHhL?=
 =?utf-8?B?cVR2SFNVcGVlUEFUQUcrK3ppTURaQ2VkZlVKVGRRVmVwbXYrSnlveFgwRm9O?=
 =?utf-8?B?dm9Sa2RWbEtOM09QVWxMQkZNb3U2Nmk3ZElvSTZmUFlhbEtNQVl6RFl5V0o4?=
 =?utf-8?B?TFlEcWVoWWhSTXUyb0RDc212K1NIbDFla0p5YVZvKzFNVGN5TVNUQzlWMmJC?=
 =?utf-8?B?WU5WeHA3RGVSRTRHWVpnMnVqUjEvTXZmcjZnU2FoOWlubmIzUHFNSDh1UHlY?=
 =?utf-8?B?NHdpeFNEVk0rbm5KSzU1SXIwdEYxM1Uxb1RjNEVGM3hYS29ZemE4UklRTjdP?=
 =?utf-8?B?MlEweVJicVhpNWFXOHBnWGp0dUtRVWtiSW1YVldZM0JhV1VsdWFxOVl0RVNL?=
 =?utf-8?B?alNZUVAxdnFtUFFGSDZJU3ZFWklqRHpjOVc0REpzR0VMaFBNR0NJMGlDNXJ6?=
 =?utf-8?B?cGpkRThjVTQwRzQwRVRJbkhOaGNVZnZmTUVrN0paQmtHSGV2VWRYZjVDYU5W?=
 =?utf-8?B?bk1MRW9FMGt2SHNrZjVPMlUweWJ1TWRNYlpMZFdxckJQazBOUEFaOW1kcXFa?=
 =?utf-8?B?SGFtWUVtOEJBK0cvTXFIVEgyR2pud0VQcnJDRlhlZjRBaFpOdFJLWTVXMVpS?=
 =?utf-8?B?dk85ZXQwb0lIaU1rdjc1NXE2WUNVOFNtRTdUWDRDRDltakQ0T0xhUHVDNjky?=
 =?utf-8?B?ektYa0FZaDJxUEJCVmp2eEpMV1h6ZzZEdjZuVXBJbTFVSGlHR2NpUlZOMXJ5?=
 =?utf-8?B?cnJ3YTU4ekN5SVMyZ21kMGJ6TUl4dTRSQ0VGRUNMMDByakJpYmZZNEY5eG9Z?=
 =?utf-8?B?OHAzZE1wRWd4eisvMXZtTzZXU0tJVUkyNy84aE5mYmZ0UlFpTnc5d0F6QnYw?=
 =?utf-8?B?OFJ2WjlOeEFJWHozbjFhMi9jNFJjUmNhUEVaRWxZWDdYamtWV0xJSEd0T3hO?=
 =?utf-8?B?cEhyKzM0UDNKSUdtZEdXcWg3RW5tNFBTd3pQSENVVEZJanpVdHR4VkxvaWo2?=
 =?utf-8?B?V01ieW9TSDYzcXJwb1F6eWRocG9XRyt2Z2t0STVTNnZmSWZ6QnhwdjdoZWN5?=
 =?utf-8?B?TGR2c3BDVXBKclBscW9XbDV4U3AycWZaUGo0Mnpwck9Ycml3ekdhWW5OeXRn?=
 =?utf-8?B?MlozeC9VemdObTFsTVJ4dVY1UHlKay94M1lwZGlOaTRaU0I5a3NxRE5WTXNi?=
 =?utf-8?B?MDFVbHl0VWZFNVJwQ0diN1Y2YkZ0OEx2VFJiL2VUUTZ2dldHc3RBSGtmRUxM?=
 =?utf-8?B?b1dEc1UrZ1ZIeVBJWERuRjJ6dEJETkxBUzMrQ3pXKzMzSFFOSFhrRTVlbTNR?=
 =?utf-8?Q?KNU8f/5i/Mz4ZCSk=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 44f8d333-6645-4098-3ee2-08da432691b2
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2022 16:56:56.0430
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: S3gVh0y78KBnE/3f9SCE/G75Uq571L05yfWWTBfkkFWLbE1iaFw48sT0MtDtrpT5UN6DdO0+1fH1yTQ8yW2ffA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB4933
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-05-31_07:2022-05-30,2022-05-31 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 suspectscore=0
 mlxlogscore=999 mlxscore=0 spamscore=0 adultscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2205310080
X-Proofpoint-ORIG-GUID: -aiL2PiysDNXBWbfQm3r0iPupoggc0FC
X-Proofpoint-GUID: -aiL2PiysDNXBWbfQm3r0iPupoggc0FC
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 5/30/22 03:10, Baolin Wang wrote:
> On 5/28/2022 6:58 AM, Mike Kravetz wrote:
> 
> I tested on my ARM64 machine with implementing arm64 specific hugetlb_mask_last_hp() as below, and it works well.
> 
> Just a few nits inline, otherwise looks good to me.
> Tested-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index d93ba128a2b0..e04a097ffcc4 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -376,6 +376,28 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
>         return NULL;
>  }
> 
> +unsigned long hugetlb_mask_last_hp(struct hstate *h)
> +{
> +       unsigned long hp_size = huge_page_size(h);
> +
> +       switch (hp_size) {
> +       case P4D_SIZE:
> +               return PGDIR_SIZE - P4D_SIZE;
> +       case PUD_SIZE:
> +               return P4D_SIZE - PUD_SIZE;
> +       case CONT_PMD_SIZE:
> +               return PUD_SIZE - CONT_PMD_SIZE;
> +       case PMD_SIZE:
> +               return PUD_SIZE - PMD_SIZE;
> +       case CONT_PTE_SIZE:
> +               return PMD_SIZE - CONT_PTE_SIZE;
> +       default:
> +               break;
> +       }
> +
> +       return ~(0UL);
> +}
> 

Thanks!  I was hesitant to put something together for those CONT_* sizes.

>>   +/*
>> + * Return a mask that can be used to update an address to the last huge
>> + * page in a page table page mapping size.  Used to skip non-present
>> + * page table entries when linearly scanning address ranges.  Architectures
>> + * with unique huge page to page table relationships can define their own
>> + * version of this routine.
>> + */
>> +unsigned long hugetlb_mask_last_hp(struct hstate *h)
>> +{
>> +    unsigned long hp_size = huge_page_size(h);
>> +
>> +    if (hp_size == P4D_SIZE)
>> +        return PGDIR_SIZE - P4D_SIZE;
>> +    else if (hp_size == PUD_SIZE)
>> +        return P4D_SIZE - PUD_SIZE;
>> +    else if (hp_size == PMD_SIZE)
>> +        return PUD_SIZE - PMD_SIZE;
> 
> Changing to use 'switch' looks more readable?

Agree.  Or, I might just go with Peter's simplification.
> 
>> +
>> +    return ~(0);
> 
> Better to return '~(0UL)' to keep function type consistent.

Yes, thanks!
-- 
Mike Kravetz