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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 987D3C2D0CE for ; Tue, 21 Jan 2020 18:51:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6F99520678 for ; Tue, 21 Jan 2020 18:51:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="TxRHhCib" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729081AbgAUSvN (ORCPT ); Tue, 21 Jan 2020 13:51:13 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:40258 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728186AbgAUSvN (ORCPT ); Tue, 21 Jan 2020 13:51:13 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00LImcsQ009200; Tue, 21 Jan 2020 18:51:03 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-2019-08-05; bh=f6ft9tle0RFZKhACFekrVTFG0KAq5griDIXNsdbXFDs=; b=TxRHhCibOlH2/ma9Ipo+Q1WBFLuQRf1qCSyLLimmT1NqWMh7UFMkL+GxGY5iYsQRdOuw SFVEpMtEdVpjjlz4Fx5B+d27z5fpIj4s91wvbQVwPETAyZ8mRaN6+7+VlvZCEsp+T212 JXhhPQWlfrcC2PW+x54j6BZTArq1kTkQ8xnUp/FhYSYmCgfpvrud8EqKpX3NzgJhd9p8 Kt3kXVgYthEoK1hgLNRbG3aMQbzZtQTObJLtP6JR9MHxAMNqXA52W5vFc2TP7vrXs0kB 029K/1pTOASVeiCdea1r7kRtMP8sA4xZsjc6YffBtAscNSlfegSpEEAfJVVnTJ2vk3H+ uA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2xktnr6x8h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jan 2020 18:51:03 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00LImIMt029574; Tue, 21 Jan 2020 18:51:02 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2xnpfpj9f4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jan 2020 18:51:02 +0000 Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 00LIp0IS011563; Tue, 21 Jan 2020 18:51:01 GMT Received: from [192.168.1.206] (/71.63.128.209) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jan 2020 10:51:00 -0800 Subject: Re: [PATCH v10 4/8] hugetlb: disable region_add file_region coalescing To: Mina Almasry , rientjes@google.com, shakeelb@google.com Cc: shuah@kernel.org, gthelen@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org, aneesh.kumar@linux.vnet.ibm.com References: <20200115012651.228058-1-almasrymina@google.com> <20200115012651.228058-4-almasrymina@google.com> From: Mike Kravetz Message-ID: Date: Tue, 21 Jan 2020 10:50:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200115012651.228058-4-almasrymina@google.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=9507 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001210140 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9507 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001210140 Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On 1/14/20 5:26 PM, Mina Almasry wrote: > A follow up patch in this series adds hugetlb cgroup uncharge info the > file_region entries in resv->regions. The cgroup uncharge info may > differ for different regions, so they can no longer be coalesced at > region_add time. So, disable region coalescing in region_add in this > patch. > > Behavior change: > > Say a resv_map exists like this [0->1], [2->3], and [5->6]. > > Then a region_chg/add call comes in region_chg/add(f=0, t=5). > > Old code would generate resv->regions: [0->5], [5->6]. > New code would generate resv->regions: [0->1], [1->2], [2->3], [3->5], > [5->6]. > > Special care needs to be taken to handle the resv->adds_in_progress > variable correctly. In the past, only 1 region would be added for every > region_chg and region_add call. But now, each call may add multiple > regions, so we can no longer increment adds_in_progress by 1 in region_chg, > or decrement adds_in_progress by 1 after region_add or region_abort. Instead, > region_chg calls add_reservation_in_range() to count the number of regions > needed and allocates those, and that info is passed to region_add and > region_abort to decrement adds_in_progress correctly. > > We've also modified the assumption that region_add after region_chg > never fails. region_chg now pre-allocates at least 1 region for > region_add. If region_add needs more regions than region_chg has > allocated for it, then it may fail. Some time back we briefly discussed an optimization to coalesce file region entries if they were from the same cgroup. At the time, the thought was that such an optimization could wait. For large mappings, known users will reserve the entire area. Smaller mappings such as those in the commit log are not the common case and are mentioned mostly to illustrate what the code must handle. However, I just remembered that for private mappings file region entries are allocated at page fault time: one per page. Since we are no longer coalescing, there will be one file region struct for each page in a private mapping. Is that correct? I honestly do not know how common private mappings are today. But, this would cause excessive overhead for any large private mapping. -- Mike Kravetz