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=-20.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 A6599C433E0 for ; Thu, 31 Dec 2020 17:56:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1B3F8223DB for ; Thu, 31 Dec 2020 17:56:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B3F8223DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2CF0D8D00B4; Thu, 31 Dec 2020 12:56:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 27F828D008E; Thu, 31 Dec 2020 12:56:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16D8A8D00B4; Thu, 31 Dec 2020 12:56:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id F0AEB8D008E for ; Thu, 31 Dec 2020 12:56:45 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B61571EE6 for ; Thu, 31 Dec 2020 17:56:45 +0000 (UTC) X-FDA: 77654332770.11.soup98_211047b274af Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 99559180F8B80 for ; Thu, 31 Dec 2020 17:56:45 +0000 (UTC) X-HE-Tag: soup98_211047b274af X-Filterd-Recvd-Size: 6097 Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Thu, 31 Dec 2020 17:56:44 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BVHsqGE063435; Thu, 31 Dec 2020 17:56:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : cc : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=Kf4i3DNvKLFdPHlgeP0pk/wrDaAfowKuwgbk2NoF3uo=; b=x7mxqys4RUCiw/dOuFjAqNNyOT3anJXub4r6W2poovyiymGYRq1MFlr+HjEKPCvkoSSu CnzOtr9XBrGgN4XLho7R5fZiwF8/Mtm2sCfahpGcNE7MCQe5gxgq8liwGJrhvrQYcyc8 xhiBAKmH9lA/45XxXYzZWGBoUM+kGnTxHmGQRhfQuToSYhKbQM9kDWZlO7k3Xeb1kQDd h3RYJnntB+yPfgwL3khWMnC7gtDKLAANAQCg6IEvCYVQlh6mnICg2I+eGTcgb77x8jxD XZWo9My7nX6Zh8bA7M74DjscaHT5Bku4f1E4vs24gLz99e2W+WoQlio+Xi3onkw++tWT CQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 35phm1jh26-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 31 Dec 2020 17:56:42 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BVHt491142535; Thu, 31 Dec 2020 17:56:41 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 35pf40etwf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Dec 2020 17:56:41 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0BVHud3L020649; Thu, 31 Dec 2020 17:56:40 GMT Received: from [192.168.2.112] (/50.38.35.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Dec 2020 09:56:39 -0800 Subject: Re: [PATCH] mm/hugetlb.c: fix unnecessary address expansion of pmd sharing From: Mike Kravetz To: Li Xinhai , linux-mm@kvack.org Cc: akpm@linux-foundation.org, Peter Xu References: <20201229042125.2663029-1-lixinhai.lxh@gmail.com> <2b6534f5-2ffa-6325-6af1-8c067ba9c0bc@oracle.com> Message-ID: <2d8a7726-b7fb-3dc8-e7bc-54a67d28db24@oracle.com> Date: Thu, 31 Dec 2020 09:56:38 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <2b6534f5-2ffa-6325-6af1-8c067ba9c0bc@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9851 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012310110 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9851 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 impostorscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012310110 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 12/29/20 1:20 PM, Mike Kravetz wrote: > On 12/28/20 8:21 PM, Li Xinhai wrote: >> The current code would unnecessarily expand the address range. Consider >> one example, (start, end) = (1G-2M, 3G+2M), and (vm_start, vm_end) = >> (1G-4M, 3G+4M), the expected adjustment should be keep (1G-2M, 3G+2M) >> without expand. But the current result will be (1G-4M, 3G+4M). Actually, >> the range (1G-4M, 1G) and (3G, 3G+4M) would never been involved in pmd >> sharing. >> >> After this patch, if pud aligned *start across vm_start, then we know the >> *start and vm_start are in same pud_index, and vm_start is not pud >> aligned, so don't adjust *start. Same logic applied to *end. >> >> Fixes: commit 75802ca66354 ("mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible") >> Cc: Mike Kravetz >> Cc: Peter Xu >> Signed-off-by: Li Xinhai > > Thank you. That does indeed fix an issue in the current code. > > Reviewed-by: Mike Kravetz Upon further thought, this patch also expands the passed range when not necessary. Consider the example (start, end) = (1G-6M, 1G-4M), and (vm_start, vm_end) = (1G, 1G-2M). This patch would adjust the range to (1G, 1G-4M). However, no adjustment should be performed as no sharing is possible. Below is proposed code to address the issue. I'm not sending a formal patch yet as I would like comments on the code first. It is not a critical issue and any fix can wait a bit. diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 7e89f31d7ef8..41ccec617f74 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5264,16 +5264,19 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, if (!(vma->vm_flags & VM_MAYSHARE)) return; - /* Extend the range to be PUD aligned for a worst case scenario */ - a_start = ALIGN_DOWN(*start, PUD_SIZE); - a_end = ALIGN(*end, PUD_SIZE); - /* - * Intersect the range with the vma range, since pmd sharing won't be - * across vma after all + * Check if start and end are within a PUD aligned range of the + * vma. If they are, then adjust to PUD alignment. */ - *start = max(vma->vm_start, a_start); - *end = min(vma->vm_end, a_end); + a_start = ALIGN_DOWN(*start, PUD_SIZE); + a_end = ALIGN(*start, PUD_SIZE); + if (range_in_vma(vma, a_start, a_end)) + *start = a_start; + + a_start = ALIGN_DOWN(*end, PUD_SIZE); + a_end = ALIGN(*end, PUD_SIZE); + if (range_in_vma(vma, a_start, a_end)) + *end = a_end; } /*