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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE664E784B7 for ; Mon, 2 Oct 2023 14:42:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 372958D0026; Mon, 2 Oct 2023 10:42:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3222B8D000E; Mon, 2 Oct 2023 10:42:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E9E98D0026; Mon, 2 Oct 2023 10:42:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0CFCE8D000E for ; Mon, 2 Oct 2023 10:42:55 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D49EE402F9 for ; Mon, 2 Oct 2023 14:42:54 +0000 (UTC) X-FDA: 81300788268.23.14356AD Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf16.hostedemail.com (Postfix) with ESMTP id BF4F218002F for ; Mon, 2 Oct 2023 14:42:52 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=NVdILmiI; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf16.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.182 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696257773; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=m9gT0sJ6bxJ7LFGJ3qcn0lur/HHwUZlrfxhEFRGE3Lc=; b=2rqTVDTUcqFQNF4p1Ctc0YfLyXGUu4eJkL0P6sUVnRM+juizrOTAd+coKw7KiFpxItBSbm 7hmRsCL3z6DvRNlBT/xB+q8lCvLTbXsa78hxIC880V4hMmIf0UzSvoPUjjnZ8Op5jBj84c VTn7DhONvTsMqxoK+dOqjejD1cUyzFU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=NVdILmiI; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf16.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.182 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696257773; a=rsa-sha256; cv=none; b=xgK1Z0ZDfREUAmJzVFDInS+lBoumD2tZUJ2ROcPciqZ5cBATDqE+T8xVJ+6EC0Q0WN3kcx M7pFrsK0npr6+mNv7qBKuDDwXWcspgNdvf76QL8AJHST7AwSlz2850yyOG4UVJKD9WskFo 8//1fzG7dCLtOiJTn/z9wS7qg4B10kQ= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-4196ae80fc3so31793101cf.0 for ; Mon, 02 Oct 2023 07:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1696257772; x=1696862572; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=m9gT0sJ6bxJ7LFGJ3qcn0lur/HHwUZlrfxhEFRGE3Lc=; b=NVdILmiIss6uoX0sequaTs+m/prxmhVXoYm0uo/q1OyjWrKd4rSt931dQaZbAABrnl 6bN5T7KcyiPanmT5ux1vJFzYS0Vd5XPtY8JBoZVrfssatXh2oBx0+PsmweZXuv8rtdLy mOFmzsgcQKlEtTWp9oi0gav/FEop/UEFYU4eanVqGqFH+cSkouFq97rCgC6NGHeC+HgU g9JTjdsjWzZJ6UAbg9xKqAeeDuhcMngVTi5n4yGQGlxGmvD4R28+IyYLa/02BkHRtCaX OqJrNSHPgMC/pBqQkLrVyG02bSqd3yRNEP9RLWnvevGHILwW36eO7ZtoP1v8KGvVKfsd jXlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696257772; x=1696862572; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m9gT0sJ6bxJ7LFGJ3qcn0lur/HHwUZlrfxhEFRGE3Lc=; b=C7fh4uisQLvQz+f69vqmVspq+Bj3jeGSgHzVcaTU27IwipnqkINA4EgvHRXyFAcufU rWXHXXuv8gVGKdyaJZKOc/m4NSmCrmuM4mIWrfUF/+XuFWVPAd+x6ssoPhXqZAerx8oC uOSXx1oflDErP74jXScH9kCgocIXpNqgol2phVPPDHwTEDO18aT8XDYFLqrr5JQanahh 8h6hlq4JO9CjA3dY4ne+AQ/aailTnwfyuZ36UcUyzE4MHjMeryn/oM6wjPhGbKoV/J6+ kBDDbF8TCxXFk/Oi7/H+pcvZ4diFbMez3qcNa6wLAwV9/RlRaSJ0s2Ccsg5XUHdyWuFe csLg== X-Gm-Message-State: AOJu0YyD/CmmvfHozE8Ihcdsgf1BzRiZuo6I5vM6OuLtRq9J4dfev1t3 ySb6aZX8P1UWXQQlS8ZUPdWePw== X-Google-Smtp-Source: AGHT+IFa+AtbCwYbo1F1bL/0dGXEiEXwwHQPJD08WSpIXpwHS50M5VhohUTqeEfXszT9O2DE8i1vpg== X-Received: by 2002:ac8:588a:0:b0:417:95e7:a2f7 with SMTP id t10-20020ac8588a000000b0041795e7a2f7mr12774184qta.19.1696257771693; Mon, 02 Oct 2023 07:42:51 -0700 (PDT) Received: from localhost (2603-7000-0c01-2716-3012-16a2-6bc2-2937.res6.spectrum.com. [2603:7000:c01:2716:3012:16a2:6bc2:2937]) by smtp.gmail.com with ESMTPSA id h20-20020ac846d4000000b0041812600a47sm6261207qto.59.2023.10.02.07.42.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 07:42:51 -0700 (PDT) Date: Mon, 2 Oct 2023 10:42:50 -0400 From: Johannes Weiner To: Mike Kravetz Cc: Michal Hocko , Nhat Pham , akpm@linux-foundation.org, riel@surriel.com, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, tj@kernel.org, lizefan.x@bytedance.com, shuah@kernel.org, yosryahmed@google.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH 0/2] hugetlb memcg accounting Message-ID: <20231002144250.GA4414@cmpxchg.org> References: <20230926194949.2637078-1-nphamcs@gmail.com> <20230927184738.GC365513@cmpxchg.org> <20231001232730.GA11194@monkey> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231001232730.GA11194@monkey> X-Rspam-User: X-Stat-Signature: 1syeg4got35ptipdmfuni9gu6eizkyy3 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BF4F218002F X-HE-Tag: 1696257772-23356 X-HE-Meta: U2FsdGVkX18Qx2AzkgvZX0Ckh5iKYqY6+em+0PU9Fqz7dq871DVeXEnok+C9KQLTCteYG+mHodKkX6K6iixH5//gwrBVSfC88dURiGQrJJO9VBECAk+yGxMMCD3ta5NUktorz3jqIz0gtTYfGgry6xQN64Uvi4Beg9JEEbaSAK/IgL/old2otFAiCFofQHk5CIvOogiHKR+Ba1XrevTDzqMFfjclgJTPIkPQuAAnZu9cRQWp6CbJbCcSM5niTZWwU+Nn15qrsdSzGv784h/KImnPcRKTB0FSBcNyJt4+TpPDMFrlgxhuITG/Y6+DQ/BaCMVsGZmW0CmP1Br94VhQRWI+zNvxvga5NPbNnB+Crg7fcZZLKZcWiqqz1uvmajzD7xO9X9kvdCQIY5JflK8RBxXkCV5AO7LYt7hFm7j4Z/zpfUOWx75BhCKXyKW1+ZvtRb0V54dnHIUnBMZLNzKy1PrxGkL08I15UdFSZQSdwHxjROAVmN6HmZYpbblhGKgKft2v6tA3fUW6ufYm9cXkrgbAnE17PbCqtF04DAwMtziqcMSOOkpISIKboFw9aNiJOZImWHM1ST8AqF9ZkkVKlIzB+s1i2IfrZMtT6pSPKGLbpnJ4Ef4UPWcrHUrTupTHhbMi9345jioEBJHpbhjlnfOYM7rgw7k2lYFIXC5Sf1XLW5JOwNJAUpnZI0NzdPlHHIKvmUSmWXqGjRpV3jfcPHxNxpYg7dA7HEIPKfTK+TAOEACLigJYU1HFxaM42tiZ0QRRGEO9tWZ+MhDDXUb1ma+5XEG1G0zPAB4n1SfssQFxX/eEkirglorJ3Be+rM2EO11bWz//HZfVhs/OGrtpUBID0V1dkK3chMF36b9Mfb9Xstd6KQzA3X/0mxP2MOQvoygKAVIYgRCAOOuP7bSK8UeIfJ7MuTOxpA5tHe/Hn3ZRvhgSxuwu4+45xNu7j40j0anSQL0Sw7usyQ/nXfK qQF6ZMxq HystL2aEKJBF+pImHMwC7s1ee0eGYFoj/SP3FQZNXfoPNHRNGNOGPt/4UyGIhFa3SfhyPjl7tp13UG4duzYZG8SuEmT4/rdTJPJMlP7+lN2q1sR8ef59Kw0smSphTbcLnp61D2f1VngP/GT3ARn4CY+sCarTxrmFjEK3jokWvN8o7YoCW5hE90pJU/ApNWuYJZvRYocDde/ySi7d8suuweC3n4FmscS9JmSU1WWgowu+xZUOEmy0lQqgWbFewTHsA8AgMIU7YKjgR2BRurA7uLZmX12rUoXrtFVvbpBJUO8O1ZwXj6wHn4ADX1SuE/8X0Vvpo/ZXppMwHJqnnzker//nGPWvCoHrLlAEOXIpB+gtAmFS8iN1Yd2LHZRMZMl99QICSuyUCuRLzdLY= 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 Sun, Oct 01, 2023 at 04:27:30PM -0700, Mike Kravetz wrote: > On 09/27/23 14:47, Johannes Weiner wrote: > > On Wed, Sep 27, 2023 at 01:21:20PM +0200, Michal Hocko wrote: > > > On Tue 26-09-23 12:49:47, Nhat Pham wrote: > > > > So that if you use 80% hugetlb, the other memory is forced to stay in > > the remaining 20%, or it OOMs; and that if you don't use hugetlb, the > > group is still allowed to use the full 100% of its host memory > > allowance, without requiring some outside agent continuously > > monitoring and adjusting the container limits. > > Jumping in late here as I was traveling last week. In addition, I want > to state my limited cgroup knowledge up front. > > I was thinking of your scenario above a little differently. Suppose a > group is up and running at almost 100% memory usage. However, the majority > of that memory is reclaimable. Now, someone wants to allocate a 2M hugetlb > page. There is not 2MB free, but we could easily reclaim 2MB to make room > for the hugetlb page. I may be missing something, but I do not see how that > is going to happen. It seems like we would really want that behavior. But that is actually what it does, no? alloc_hugetlb_folio mem_cgroup_hugetlb_charge_folio charge_memcg try_charge !page_counter_try_charge ? !try_to_free_mem_cgroup_pages ? mem_cgroup_oom So it does reclaim when the hugetlb hits the cgroup limit. And if that fails to make room, it OOMs the cgroup. Or maybe I'm missing something?