Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp945900ybv; Wed, 5 Feb 2020 17:45:11 -0800 (PST) X-Google-Smtp-Source: APXvYqwszjGRhgw9G0e+90lyJTQec+Szn6A6/32f3uB60aK6EZPcwGIJSHbUn8E38HEJgt7rwsQp X-Received: by 2002:aca:bb54:: with SMTP id l81mr5147782oif.175.1580953511332; Wed, 05 Feb 2020 17:45:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580953511; cv=none; d=google.com; s=arc-20160816; b=BbMKaIJ8fSwP5Ti9lNIiKcPgEC7LkGowQgN7Zc/bIgiUmTm+hwqddP9IGnbgOI2H92 usKubzMJkHaK9v5EBPPWoYJaCSQq6GcwcHwPkldlKDY6zTvVw7ejjQPlRdbMsn/4IB97 0kHF5z82n4SJCdaYT9ysQU+HAHusN3MX5Kz1JxlbSUZbQHiD98kqSABZH8I/jw0D25vy SkE+pzHz+despEuWi72ZOht6MHnozZvwMmVuyfws6zf4qK4I02bZ4vixKwTtK53II1/k Lw950MxoCDGzCg6kf48Z1aq/YITlFgqFavvCVYaWkzuVDdDZorVKZS38AP2gX3Jtgllw l3Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=rSnhPc5sm1WKX1AxY5ecWiqStcBUxMiXywxGfVIJb3s=; b=C6+fwCb44+2Mwz7MpnjVzTZp457ruKO0CJhg4kmyRMcZJsxLJEuMSWC1NzqHLmb6PT QkzlTexyYI+RD2Fi7xs0xUubqhQxU2BCkixWsi6lWCibxEkxN2r8fa/Y2Zwf+b3iUNkD 337nYjPLyCuI4NE5e2cJV36WkR77p7J+ukaGYBVFXWKkt/ePZJg7ttEHUQ8YAhebkTF3 8ztGENfiTInUTivCJyO3nhdPpGSU2E3Th1TZDPsNq7ffBVItCVJjf1A3WiuS4SiXiSGD LtPs+8ejxJaoqX1RYjD2j1nErV8OmR4qI39fpIcqA41ndjdsEaboX0MKiys3MAPXeMMg GVKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=hASTENvQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i124si1267432oif.214.2020.02.05.17.44.59; Wed, 05 Feb 2020 17:45:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=hASTENvQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727474AbgBFBnz (ORCPT + 99 others); Wed, 5 Feb 2020 20:43:55 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:38577 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727415AbgBFBnz (ORCPT ); Wed, 5 Feb 2020 20:43:55 -0500 Received: by mail-oi1-f196.google.com with SMTP id l9so2955110oii.5 for ; Wed, 05 Feb 2020 17:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rSnhPc5sm1WKX1AxY5ecWiqStcBUxMiXywxGfVIJb3s=; b=hASTENvQqDefynTK3/vPCP/JkgvLwj9TJiEC2KANfBjieXUCLbbJfgFb70CSl/h83z iyWGWjOz4tmmSIm397EoWDsVhES3vq0zkHC5G5EGe5VJjXCqr7AkD86ECgwEo/5q0UTF L5koUiwcvP4A3K4/dOMmYL+zCNVKb1K3ADX8bfLwh5rd5G+4ohXyQU8ov/3BhHpEr21D sibOcthDDa1c/SkgDfSJbmDZaiBTSmGhm3++rP6osHO4gOPP5OhPfHvZUU+4eOIsrJjD WQeP9qF/Sw4MIVCx+iXVf1QlAvw0Hy07hLYY9cmunHVp6AMkyt/cih1uWc8NwQDRhEeZ zhSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rSnhPc5sm1WKX1AxY5ecWiqStcBUxMiXywxGfVIJb3s=; b=bhNASgsWl8AUZakMPF+SRIT6LBCDeiKVbXCx6NnmbfCPa+IZL/KnjpcxDcPqpFt4Pv tMLHkC3iKtCGWK9kY6O/V5dQOTCKpnYErsfPJ9J8p12hS0eOAu+3nlDSXtKDQnroBwUr fKi1IpAuKnIUSsnh8e98elB5b/XsVmkcO4JDcbsnxzmlOsjts6gpxt/DlNaIR+gWtsI9 EDR3I+xZUA/B67Yn0epFif4zpChhl1Hv4urBTN8ejgeDQR4x7s7HwYrxOBpBGKyGyzvj UqqD7X94pM0JodsEwbOvP/pOIJxKBLMRjFwwL4GxGL07AI9LC5MKfqYaJfwn2ErdhM2m sapQ== X-Gm-Message-State: APjAAAUSBSnrT1qLWzmnNT4p4PXJSXRygy9aGNQQDagcPY+kobFcI5VQ 1wYZ7zvupiorWwquN1H5wh6QJ69uGrorFjZ5/u0Z0g== X-Received: by 2002:aca:d6c8:: with SMTP id n191mr5503972oig.103.1580953434139; Wed, 05 Feb 2020 17:43:54 -0800 (PST) MIME-Version: 1.0 References: <20200203232248.104733-1-almasrymina@google.com> <20200203232248.104733-4-almasrymina@google.com> In-Reply-To: From: Mina Almasry Date: Wed, 5 Feb 2020 17:43:43 -0800 Message-ID: Subject: Re: [PATCH v11 4/9] hugetlb: disable region_add file_region coalescing To: Mike Kravetz Cc: shuah , David Rientjes , Shakeel Butt , Greg Thelen , Andrew Morton , open list , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 5, 2020 at 3:57 PM Mike Kravetz wrote: > > On 2/3/20 3:22 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. > > > > Signed-off-by: Mina Almasry > > Reviewed-by: Mike Kravetz > > This is the same as the previous version. My late comment was that we > need to rethink the disabling of region coalescing. This is especially > important for private mappings where there will be one region for huge > page. I know that you are working on this issue. Please remove my > Reviewed-by: when sending out the next version. > Yes to address that there is a new patch in the series, which re-enables the coalescing when the hugetlb cgroup uncharge info is the same. I guess it could be squashed with this one but I thought it was better to implement that patch on top of the patch that enabled shared accounting, because that is the patch that sets hugetlb cgroup info on the file region entries. Let me know what you think. > Thanks, > -- > Mike Kravetz