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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C41A0C35247 for ; Thu, 6 Feb 2020 01:43:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 81B8A214AF for ; Thu, 6 Feb 2020 01:43:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="hASTENvQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81B8A214AF Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2BA0D6B0003; Wed, 5 Feb 2020 20:43:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 26AFA6B0006; Wed, 5 Feb 2020 20:43:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1596B6B0007; Wed, 5 Feb 2020 20:43:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id EDD226B0003 for ; Wed, 5 Feb 2020 20:43:55 -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 A814B2494 for ; Thu, 6 Feb 2020 01:43:55 +0000 (UTC) X-FDA: 76458006030.11.steel22_3f5a0e6cbdf20 X-HE-Tag: steel22_3f5a0e6cbdf20 X-Filterd-Recvd-Size: 5459 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 01:43:55 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id z2so2961872oih.6 for ; Wed, 05 Feb 2020 17:43:55 -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=hxVOvnCFeqlR8nE7vHzsXOpPfnJ3fG+Tu/nNuJdX1X98LgpqsY9vJAQO4RQ7shm1d7 /1+oDi81o397gJSTcR50i4umHDBGFRnx2vcAxX5zANJ0OuBFvkZeMIr85DGM+PDt3bll xfg8ZHZL4G5HbMTLWQPpT0xnmaqwOfZcPYPFiVLcqumj3DVGr5e1BUHklhf6pH8mFtUP wPL056nDOLevRC2auh14yjayaK5WZnIS/4ncW64g/NV+I6KWcTaFvoy9b1BgPw5dZ/Yh 2D2fH5Y3JGEhhStQ7qFNqCzhkIQCUXsVm6VlQ2BDhpfROG/D4V6xGb9/+VNUEDpYA1mB WqcQ== X-Gm-Message-State: APjAAAXHHD6U4NJkEA7DWKvrXcBEi+sxJ415SBibqICaAUmkfP8hSuHY jjWRn/4K4MUMO2dXa0m5Go8Fkgl1LCWh7YoVpU/FuQ== X-Google-Smtp-Source: APXvYqz+vL5vVc3c3EqGorwKWyApF85gPLUz0qAt0tCjSSmjl8jJi5+mOSnq4Lof7/Jvq/soGG7yZ4hZZPC28aas1Qs= 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" 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 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