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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,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 5808DC433DB for ; Tue, 29 Dec 2020 21:20:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBEEC21D1B for ; Tue, 29 Dec 2020 21:20:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBEEC21D1B 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 0E4488D003B; Tue, 29 Dec 2020 16:20:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 094F98D002C; Tue, 29 Dec 2020 16:20:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC7418D003B; Tue, 29 Dec 2020 16:20:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id D72A58D002C for ; Tue, 29 Dec 2020 16:20:49 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8D9178249980 for ; Tue, 29 Dec 2020 21:20:49 +0000 (UTC) X-FDA: 77647589418.15.guide56_58076502749f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 6DEDF1814B0C1 for ; Tue, 29 Dec 2020 21:20:49 +0000 (UTC) X-HE-Tag: guide56_58076502749f X-Filterd-Recvd-Size: 5051 Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Dec 2020 21:20:48 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTLG03N192332; Tue, 29 Dec 2020 21:20:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=eFESUH8GWfZ1gN4paNPHXSLPdl8NAtvnMuPfXNkkdpw=; b=peBZEDwXIMzB31kfawXiHEa4AOahwv+GugqjszdPK1JQbMx8bz+Ja7uI4Wbr2DcifUuG 3xWIPaq59+QS+9xh0AFxnK/iWAp+Es97ny+YmG6sYjx4FN3l/w5Ttrp/6Hddu2mWVp8a CSszkfl9SwdlCiPff53mzpBKVLZh+ne4yW0YRhDc28GRTQ6ll7O9BNC5sRNxqo7051mF HlzxvCKldkle7sHkp1CxEw9GZfSaPX3MpfAy5u3c1fpR7jfLcaqigoH6bxjVhD6z+dcp GRCKYzCV7lzs9wEYfGyDoW1pGu8FBDr0ImkicxrD37zzke6a+TQeYmSrr3S8H80wH8fw LA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 35nvkqqab4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 Dec 2020 21:20:46 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTLAMa9127261; Tue, 29 Dec 2020 21:20:45 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 35pf2xe90q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Dec 2020 21:20:45 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0BTLKfwn016216; Tue, 29 Dec 2020 21:20:41 GMT Received: from [192.168.2.112] (/50.38.35.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Dec 2020 13:20:41 -0800 Subject: Re: [PATCH] mm/hugetlb.c: fix unnecessary address expansion of pmd sharing To: Li Xinhai , linux-mm@kvack.org Cc: akpm@linux-foundation.org, Peter Xu References: <20201229042125.2663029-1-lixinhai.lxh@gmail.com> From: Mike Kravetz Message-ID: <2b6534f5-2ffa-6325-6af1-8c067ba9c0bc@oracle.com> Date: Tue, 29 Dec 2020 13:20:40 -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: <20201229042125.2663029-1-lixinhai.lxh@gmail.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=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 malwarescore=0 suspectscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290131 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 bulkscore=0 adultscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290131 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/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 Andrew, You asked about user-visible runtime effects. The 'adjusted range' is used for calls to mmu notifiers and cache(tlb) flushing. Since the current code unnecessarily expands the range in some cases, more entries than necessary would be flushed. This would/could result in performance degradation. However, this is highly dependent on the user runtime. Is there a combination of vma layout and calls to actually hit this issue? If the issue is hit, will those entries unnecessarily flushed be used again and need to be unnecessarily reloaded? -- Mike Kravetz