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 83B3FC3DA41 for ; Tue, 9 Jul 2024 13:06:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7736B0099; Tue, 9 Jul 2024 09:06:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1577D6B009B; Tue, 9 Jul 2024 09:06:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01F456B009C; Tue, 9 Jul 2024 09:06:02 -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 D7A406B0099 for ; Tue, 9 Jul 2024 09:06:02 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 18A57A4F2D for ; Tue, 9 Jul 2024 13:06:02 +0000 (UTC) X-FDA: 82320236964.11.E851A68 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by imf19.hostedemail.com (Postfix) with ESMTP id DEBC21A0019 for ; Tue, 9 Jul 2024 13:05:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=VIi6mpjY; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720530335; a=rsa-sha256; cv=none; b=4Nl6e0QG3MmGKaqFKodHuV+SCKNtPhnplt3Wo1YAE3IXK+Pp2+ndYYJMGEu9SwuDwejyIq MUKcQOFmyn7LzMhFN0vqsJYHeR8JoqaeULCbS9LCnS/4EghJ6WHmwL8HxJ5BwGUo9nqaV6 6rfNSeWDPkUwM9U/e190yFd65T0rqEU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=VIi6mpjY; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720530335; 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=LhBjgRzpL9sQaVK76pu/ld0xnGk1Z8E8uhy7X7mxsF4=; b=j2K6xrc5v9IY6qXFQZsIr5ckww0WgIbP6HDotoxW3Aw2xkH+3kln8aLDOfoejFt2dO+7e3 4petfoIg8ZkKOF5K8jT/J2nElKDI3Y2qFUSZg1tvOvKuSoCucanbhsW6WNyFcensXRdqwv IqbTjEbbaT3vWTt4M/iEqR10AO2jltg= Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2eea8ea8bb0so35610631fa.1 for ; Tue, 09 Jul 2024 06:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1720530358; x=1721135158; 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=LhBjgRzpL9sQaVK76pu/ld0xnGk1Z8E8uhy7X7mxsF4=; b=VIi6mpjYLQDnX1POBnWxCpzrGBQn1UXcxVOTTR9Fmc8qhHNJoSd2RFdqp02Syx1ydM jZIhGuQDN28fnmZ3rZFKI3NDzCMlD6gUBrrRNDGc4YIDJrKygk/olTyaV/uKjz88FwsR gTSfTwNWwOaii06WZJ+NP37ySctBZUHnakh285XiFC/NoFqxtAIVIOD08LPM3yzHLqhR sEoSOMjHKiNmsCW0Euce1OJDOezbvox+OZ4rpeRBeCFfQPcktZa8msDrjPCJDcln3JFB 4jZudg0mGTduywXLOBvwq+spUuiXa7/KMLRyTUivX+XGpkDS8c3MITjeIsKkqFm+Rzid ljUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720530358; x=1721135158; 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=LhBjgRzpL9sQaVK76pu/ld0xnGk1Z8E8uhy7X7mxsF4=; b=BVbcD6+/2dDbl1aT5Nlr/ffBPSP9GyROz6EOjFhwv6wPVQRon1VEtpv4UscRqWMjvI OkkYO/3WaaY64ElopSvMjpFwncVxze4rZBVrHaAqI2LLVepK8fSNQxyF/VIcpBE5+E8g KLvpSZTvh903AHOCVDk6c3UKn+jbMjtFXud/akkkbCfWy1boKx+Vh48HQvdmbn+lUkBz c/LkPq0KGFKvPibJjoJa9hBNIVbswfTfQXHORTkBsiMvNIXE+xu+a60qUgPWRw4eggKb NeFXoE6HljTGloeUwToyezR9/vXDfsv23l1ANSSp4Z04uCAaSKRVtyRf1xhIo2YozzXv Ahpg== X-Forwarded-Encrypted: i=1; AJvYcCXNPpZJJveWBLw4IHNbqlRHczd0kBXmIZy5/N48m8pju6jHD0u4vDbd8nxRUtV/LlECupvKBbUYUM4MhMXqmPo4Lr8= X-Gm-Message-State: AOJu0YzX9nCZ6yE96QClE1pjnVLn+ADA0Q9Tkq/HZAyKLw//9JX2x6Bb wGAre/9Gvc+PzHfm36LuhXCRbATmLVrB8sW6LGRrISs6zW7jr22+xLtYsZNX8n8= X-Google-Smtp-Source: AGHT+IHOTh69D3Wwh5wXN48yiquSobzGhHe+Le3Ut78ADxB5tyf8MU7GHpgjRa1MPh1vOGvXyEFoJw== X-Received: by 2002:a2e:9693:0:b0:2ec:165a:224d with SMTP id 38308e7fff4ca-2eeb3169f03mr20727561fa.38.1720530358111; Tue, 09 Jul 2024 06:05:58 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a780a871fe1sm76017166b.223.2024.07.09.06.05.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jul 2024 06:05:57 -0700 (PDT) Date: Tue, 9 Jul 2024 15:05:55 +0200 From: Michal Hocko To: xiujianfeng Cc: Andrew Morton , tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org, corbet@lwn.net, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sidhartha Kumar , Miaohe Lin , Baolin Wang Subject: Re: [PATCH -next] mm/hugetlb_cgroup: introduce peak and rsvd.peak to v2 Message-ID: References: <20240702125728.2743143-1-xiujianfeng@huawei.com> <20240702185851.e85a742f3391857781368f6c@linux-foundation.org> <6843023e-3e80-0c1c-6aab-b386ffebd668@huawei.com> <20240703133804.1d8ddf90f738a7d546399b3b@linux-foundation.org> <5ce7be39-ac42-98c9-65fc-589385b8f65b@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DEBC21A0019 X-Stat-Signature: 5p97ksaxznsur6oxwws7wz9x1a8qdu3o X-Rspam-User: X-HE-Tag: 1720530359-853621 X-HE-Meta: U2FsdGVkX18kF3IHwPtZHFXqHn2He+/bY7W1e8GaYK9yQ7XGNck3VygE3S4giPkaHf8ILKjOeuuA6iyoEkG7G3WMkt1vJTbqycW4WDIvji9NCBAK6UcHUu+IztmhsEwedqnw3E+dlwkqZBqdj4wt7roOsaOziGUSZ+IzPTwyKAGraaZY9wNWX4EapdFqj6VdgNbICvvSzRMDWBq5IqwuZoQ66Nbcj5nX9PHtchjBAcTbDSjR9Qz+XRMZEqvBoVHvABC4NQaC/QMMTzJbRGZTXEzJHCTCyrsuIyVL9ls6wdj0TEvTm7KiGr3N5hOzl1P3mv2khH8QLqKZuXKXbrp2FFkWZQVQZR0kq1766hWuY09H8tXp9/g6DIO4zUEGUMJILyi4DRhdBY7vzgNL957I8/DMCOtyZAWYKyPJhGOTZu50eYrLSz33K9+qKOmOGCLrka4t3qyzDYoeg8HAAhRHeXjcpiR7ICWCNFvrRnDq4UrL4V/ZSdaem/fxGI02tIVRGtEb5KDI/r4h4/2Pb3TX9xMDSIHazcWIpuzy4G9JFE02HiQKzO08NgXHXIqMmIalUlQhgENVIfC4RuS9jaIhUHdz6dxZ+Ww014IYk60z7PYoq/oTqdA+Kn+44D6+9nIieiXK1+A1VG233OTMvGte6nAfhzR0LmdbnvsSf7/XoeLd2q6hLQIv/5KX2erler0bN8zDNvx5lejApJ2Oksj/OUxNgPyQHUWDbxJxscxZWlB7oc40XRyMISM2swj4VsYNDiuDMFz5TN75AKopvN8FJo7J+OhxZ2rlrMiczyunhzeL4HLdhmpnnlUVFZPIwRwAxel+//RLVGYwLEN9YkPNPyY6wDS4rbKgzKaLToZwC8X0Rh8MrWAh/Am3cq1C4Abxlcfssq8ekKX0htxc3eJSjVAg7QcghIs8jnfKGFh2qDT+utRl7M5eziC4dlB1fYwY1aWOEodOUcXR0b/g8bR LjW0dW8Q GMSd2+27DDixeBUMt8dOSLnnlcN3sqd90RA8Onm9lLIwBuRsVoMXd4kxlg8j3EvD22f5JQ3TsAV9LfG07CJ+mr4oUC10TCcCjv/XrIdYjZok006cOQLcpWoXMTiut7rWVydEoxF7eUPDUaEHiMtNYCNk3noQJCyOHim1n7JQjV0DdTIXhDm+xsrdT7pbdhehMwAzxaJbvSwRdNvEgC5mOEwDrlSEmuyDhAm+Y2P/UaCLiv5Fnh5oMsv/2dgM12HKm/q4aPtxZ8bdrNfqR8MkCn57bNdRoDuFFQBOXGl5RIYutZSb4G351PlBKI4T3aPu/kWfGfdK9WR8c0L2OUw41A9BMaC3bnT+7pC5N1l8zWgFn9iA= 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: List-Subscribe: List-Unsubscribe: On Tue 09-07-24 20:47:30, xiujianfeng wrote: > > > On 2024/7/9 0:04, Michal Hocko wrote: > > On Mon 08-07-24 21:40:39, xiujianfeng wrote: > >> > >> > >> On 2024/7/8 20:48, Michal Hocko wrote: > >>> On Wed 03-07-24 13:38:04, Andrew Morton wrote: > >>>> On Wed, 3 Jul 2024 10:45:56 +0800 xiujianfeng wrote: > >>>> > >>>>> > >>>>> > >>>>> On 2024/7/3 9:58, Andrew Morton wrote: > >>>>>> On Tue, 2 Jul 2024 12:57:28 +0000 Xiu Jianfeng wrote: > >>>>>> > >>>>>>> Introduce peak and rsvd.peak to v2 to show the historical maximum > >>>>>>> usage of resources, as in some scenarios it is necessary to configure > >>>>>>> the value of max/rsvd.max based on the peak usage of resources. > >>>>>> > >>>>>> "in some scenarios it is necessary" is not a strong statement. It > >>>>>> would be helpful to fully describe these scenarios so that others can > >>>>>> better understand the value of this change. > >>>>>> > >>>>> > >>>>> Hi Andrew, > >>>>> > >>>>> Is the following description acceptable for you? > >>>>> > >>>>> > >>>>> Since HugeTLB doesn't support page reclaim, enforcing the limit at > >>>>> page fault time implies that, the application will get SIGBUS signal > >>>>> if it tries to fault in HugeTLB pages beyond its limit. Therefore the > >>>>> application needs to know exactly how many HugeTLB pages it uses before > >>>>> hand, and the sysadmin needs to make sure that there are enough > >>>>> available on the machine for all the users to avoid processes getting > >>>>> SIGBUS. > >>> > >>> yes, this is pretty much a definition of hugetlb. > >>> > >>>>> When running some open-source software, it may not be possible to know > >>>>> the exact amount of hugetlb it consumes, so cannot correctly configure > >>>>> the max value. If there is a peak metric, we can run the open-source > >>>>> software first and then configure the max based on the peak value. > >>> > >>> I would push back on this. Hugetlb workloads pretty much require to know > >>> the number of hugetlb pages ahead of time. Because you need to > >>> preallocate them for the global hugetlb pool. What I am really missing > >>> in the above justification is an explanation of how come you know how to > >>> configure the global pool but you do not know that for a particular > >>> cgroup. How exactly do you configure the global pool then? > >> > >> Yes, in this scenario, it's indeed challenging to determine the > >> appropriate size for the global pool. Therefore, a feasible approach is > >> to initially configure a larger value. Once the software is running > >> within the container successfully, the maximum value for the container > >> and the size of the system's global pool can be determined based on the > >> peak value, otherwise, increase the size of the global pool and try > >> again. so I believe the peak metric is useful for this scenario. > > > > This sounds really backwards to me. Not that I care much about peak > > value itself. It is not really anything disruptive to add nor maintain > > but this approach to configuring the system just feels completely wrong. > > You shouldn't be really using hugetlb cgroup controller if you do not > > have a very specific idea about expected and therefore allowed hugetlb > > pool consumption. > > > > Thanks for sharing your thoughts. > > Since the peak metric exists in the legacy hugetlb controller, do you > have any idea what scenario it's used for? I found it was introduced by > commit abb8206cb077 ("hugetlb/cgroup: add hugetlb cgroup control > files"), however there is no any description about the scenario. I do not remember but I suspect this is mimicts other cgroupv1 interfaces. -- Michal Hocko SUSE Labs