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=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 04A1DC433E0 for ; Tue, 22 Dec 2020 22:55:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8581122B2D for ; Tue, 22 Dec 2020 22:55:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8581122B2D 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 992046B0085; Tue, 22 Dec 2020 17:55:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 943796B0087; Tue, 22 Dec 2020 17:55:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BDF86B0088; Tue, 22 Dec 2020 17:55:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 608BA6B0085 for ; Tue, 22 Dec 2020 17:55:47 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 26B7D1EE6 for ; Tue, 22 Dec 2020 22:55:47 +0000 (UTC) X-FDA: 77622427134.28.wall92_1d1194f27463 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id EF58D6C26 for ; Tue, 22 Dec 2020 22:55:46 +0000 (UTC) X-HE-Tag: wall92_1d1194f27463 X-Filterd-Recvd-Size: 5154 Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 22:55:46 +0000 (UTC) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BMMpWlD174018; Tue, 22 Dec 2020 22:55:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=N+6K3mCeYK/CoMCgVBBUHQgK04gVj9asaTrrtBEH5II=; b=xMjE8Cj23ZoYzPmldN5IYeUk4iWwtF72gnepmDtV597NPn+XfF/jb1Yqrc4kKLw8UPuO PuF+Gz3HXDcBc8LC/BTKqPlOSqus6fuXw1pYdzahisjKl8VvplckbgiyU4x5/a0YAlA5 pvvmTYnW+6aTLZ+MmYu5u+nPG0qfNtOB+LJZVbltZ1NPMgEk+3WkY6XpZYmQqog0CkBa pBHUX6Ng/TtbZo+eFfHgMj8dxB2ZNakMuz8QmkhyC2kX5wLAuh4l+nO2UADVxEcBKLAK g5RCX73Cbryr+0+2pEz/MzI+NpM0d6/yup1ELAwRsjFUI1THCc84UNGYBpn1IWzB/fUQ iA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2130.oracle.com with ESMTP id 35k0d15m2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 22 Dec 2020 22:55:35 +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 0BMMnvTk007881; Tue, 22 Dec 2020 22:55:35 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 35k0ea3sym-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Dec 2020 22:55:35 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BMMtUxk026442; Tue, 22 Dec 2020 22:55:31 GMT Received: from [192.168.2.112] (/50.38.35.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Dec 2020 14:55:30 -0800 Subject: Re: [RFC PATCH 1/3] mm: support hugetlb free page reporting To: Alexander Duyck , Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , David Hildenbrand , Jason Wang , Dave Hansen , Michal Hocko , Liang Li , Liang Li , linux-mm , LKML , virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org References: <20201222074656.GA30035@open-light-1.localdomain> From: Mike Kravetz Message-ID: <52a6cb93-1fed-dfd7-d21e-f14197a9c9dc@oracle.com> Date: Tue, 22 Dec 2020 14:55:28 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9843 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012220165 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9843 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 adultscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 clxscore=1011 phishscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012220165 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/22/20 11:59 AM, Alexander Duyck wrote: > On Mon, Dec 21, 2020 at 11:47 PM Liang Li wrote: >> + >> + if (huge_page_order(h) > MAX_ORDER) >> + budget = HUGEPAGE_REPORTING_CAPACITY; >> + else >> + budget = HUGEPAGE_REPORTING_CAPACITY * 32; > > Wouldn't huge_page_order always be more than MAX_ORDER? Seems like we > don't even really need budget since this should probably be pulling > out no more than one hugepage at a time. On standard x86_64 configs, 2MB huge pages are of order 9 < MAX_ORDER (11). What is important for hugetlb is the largest order that can be allocated from buddy. Anything bigger is considered a gigantic page and has to be allocated differently. If the code above is trying to distinguish between huge and gigantic pages, it is off by 1. The largest order that can be allocated from the buddy is (MAX_ORDER - 1). So, the check should be '>='. -- Mike Kravetz