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.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,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 11F66C4360C for ; Thu, 26 Sep 2019 19:28:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CF6042245A for ; Thu, 26 Sep 2019 19:28:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="VYrL4qkf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF6042245A 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 6836F8E0015; Thu, 26 Sep 2019 15:28:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 634CF6B0275; Thu, 26 Sep 2019 15:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 522708E0015; Thu, 26 Sep 2019 15:28:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 332166B0274 for ; Thu, 26 Sep 2019 15:28:16 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 8E4E18794 for ; Thu, 26 Sep 2019 19:28:15 +0000 (UTC) X-FDA: 75978057750.28.talk81_dd1ce631085d X-HE-Tag: talk81_dd1ce631085d X-Filterd-Recvd-Size: 6092 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Sep 2019 19:28:14 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id y10so62834plp.2 for ; Thu, 26 Sep 2019 12:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=MPY9mLobCsFCdGTyhVub8qrg9jLGGnIpfTk+BisJCH8=; b=VYrL4qkfnIoJrXhQd4N/uNnqbiyr0k4cU5NBaiNVQ648M7nmosCB93lB4YioJ8uFMn 66ApM6ofqMqBsXccCOTc4B4eMP5whHQ/qS1OvSBcwUVi5afpmn1lOiMb6dKwFhnHJIbJ KYjML4oqBtqr88sdA6pv1lxhcELEjTl06Y7scpK3CarFPh8/khNXk7ftZqi710Db2oms nfRxRuETzBWF0hjP9Is7uo9VGJpqPAozmDMQRme3O+FTd0J5h5Id+Ydm1aUx3NXI+sh0 BEa7zLccBudk4dj6ZlnVUCwcLP9gpavNz9Me5fn7dxcwJgNbiAIc1520e1/MBu9vS2hk aQ2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=MPY9mLobCsFCdGTyhVub8qrg9jLGGnIpfTk+BisJCH8=; b=eNBEPibpcB5MakFW8/zz7g0wV/6Y71GBJQxTC2MNEmdv/OK230xVDtmdbS1S7nPnVG b0icW32tVT5fUKmJDH1uNXUPXy91p4nHJG5S1dUMVyTPcvxQS0WtJkicM5i+h6DmIFzp js2jZXM2jfkGrsGBi+xi910gqgTigNsh5+rOajwIcy2uqTB4dxJVucdMU8/fCYXdwXTj Di8+YfORqpUVVCc4pLHbTyXY2nZlTzycbHkB6814dmUtYGk+4BAEbsMSVJRKIXER6e0p PzYVBC0C2gNJz+zjETp1QafDSkfNlCejoGZbVadS65NHNa6scI74k5alfQwrcOxqWcQZ S77A== X-Gm-Message-State: APjAAAVvChuoouOBD4REnRMRgki7NkRA6afzJAFM5lEgKPqqu3saOrwM +HTE4sfFLJ8HHd1q+jPQAEdsKg== X-Google-Smtp-Source: APXvYqwQv1h8+xAWm6OIXAeweA7guotoMUQPeA635I7aV4IJbD4SmqA/ZxJLNxKi7FavCZOcyKsUww== X-Received: by 2002:a17:902:720a:: with SMTP id ba10mr215767plb.328.1569526093196; Thu, 26 Sep 2019 12:28:13 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id c125sm66697pfa.107.2019.09.26.12.28.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 12:28:12 -0700 (PDT) Date: Thu, 26 Sep 2019 12:28:11 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Mina Almasry cc: Mike Kravetz , Aneesh Kumar , shuah , Shakeel Butt , Greg Thelen , Andrew Morton , khalid.aziz@oracle.com, open list , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org, =?UTF-8?Q?Michal_Koutn=C3=BD?= Subject: Re: [PATCH v5 0/7] hugetlb_cgroup: Add hugetlb_cgroup reservation limits In-Reply-To: Message-ID: References: <20190919222421.27408-1-almasrymina@google.com> <3c73d2b7-f8d0-16bf-b0f0-86673c3e9ce3@oracle.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Tue, 24 Sep 2019, Mina Almasry wrote: > > I personally prefer the one counter approach only for the reason that it > > exposes less information about hugetlb reservations. I was not around > > for the introduction of hugetlb reservations, but I have fixed several > > issues having to do with reservations. IMO, reservations should be hidden > > from users as much as possible. Others may disagree. > > > > I really hope that Aneesh will comment. He added the existing hugetlb > > cgroup code. I was not involved in that effort, but it looks like there > > might have been some thought given to reservations in early versions of > > that code. It would be interesting to get his perspective. > > > > Changes included in patch 4 (disable region_add file_region coalescing) > > would be needed in a one counter approach as well, so I do plan to > > review those changes. > > OK, FWIW, the 1 counter approach should be sufficient for us, so I'm > not really opposed. David, maybe chime in if you see a problem here? > From the perspective of hiding reservations from the user as much as > possible, it is an improvement. > > I'm only wary about changing the behavior of the current and having > that regress applications. I'm hoping you and Aneesh can shed light on > this. > I think neither Aneesh nor myself are going to be able to provide a complete answer on the use of hugetlb cgroup today, anybody could be using it without our knowledge and that opens up the possibility that combining the limits would adversely affect a real system configuration. If that is a possibility, I think we need to do some due diligence and try to deprecate allocation limits if possible. One of the benefits to separate limits is that we can make reasonable steps to deprecating the actual allocation limits, if possible: we could add warnings about the deprecation of allocation limits and see if anybody complains. That could take the form of two separate limits or a tunable in the root hugetlb cgroup that defines whether the limits are for allocation or reservation. Combining them in the first pass seems to be very risky and could cause pain for users that will not detect this during an rc cycle and will report the issue only when their distro gets it. Then we are left with no alternative other than stable backports and the separation of the limits anyway.