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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C2E4C433EF for ; Thu, 30 Sep 2021 10:46:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C29FF619EA for ; Thu, 30 Sep 2021 10:46:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C29FF619EA Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C53A3940096; Thu, 30 Sep 2021 06:46:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C032294003A; Thu, 30 Sep 2021 06:46:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF15C940096; Thu, 30 Sep 2021 06:46:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id 9D37294003A for ; Thu, 30 Sep 2021 06:46:46 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5CDF027DE4 for ; Thu, 30 Sep 2021 10:46:46 +0000 (UTC) X-FDA: 78643911612.21.0925DD8 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf07.hostedemail.com (Postfix) with ESMTP id AB42810001EB for ; Thu, 30 Sep 2021 10:46:45 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 406152244D; Thu, 30 Sep 2021 10:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1632998804; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BNpEAPfqLAT1sidWYZ6xZ12IH1z9JTW4BAwDBqrqY1M=; b=uho8J6OpexOUbOsojbEXfHP1SySqKDqXzfXn0+V7jn1Aju7vwb0NXIJIUouFeDj2PP7fEG cwNVk/U8fS9VnlQpOnpnZV1rtjwvwj7Cc6mz8gZocMjmtU4T888uMJWaSSHyiD/A0slolD ulsYnsnszM/w5eM7VbdYgllGX6Gl9EU= Received: from suse.cz (mhocko.udp.ovpn2.prg.suse.de [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id BCD67A3B9E; Thu, 30 Sep 2021 10:46:40 +0000 (UTC) Date: Thu, 30 Sep 2021 12:46:43 +0200 From: Michal Hocko To: Baolin Wang Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] Support hugetlb charge moving at task migration Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: AB42810001EB X-Stat-Signature: gi5r6qmirdnm1wkr3sqseiqput1srhtg Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=uho8J6Op; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1632998805-912908 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 29-09-21 18:19:26, Baolin Wang wrote: > Hi, > > Now in the hugetlb cgroup, charges associated with a task aren't moved > to the new hugetlb cgroup at task migration, which is odd for hugetlb > cgroup usage. Could you elaborate some more about the usecase and/or problems you see with the existing semantic? > This patch set adds hugetlb cgroup charge moving when > migrate tasks among cgroups, which are based on the memcg charge moving. Memcg charge moving has shown some problems over time and hence this is not part of cgroup v2 interface anymore. Even for cgroup v1 this has been an opt-in. I do not see anything like that in this patch series. Why should all existing workloads follow a different semantic during task migration now? > Please help to review. Thanks. > > Baolin Wang (2): > hugetlb_cgroup: Add interfaces to move hugetlb charge at task > migration > hugetlb_cgroup: Add post_attach interface for tasks migration > > mm/hugetlb_cgroup.c | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 230 insertions(+) > > -- > 1.8.3.1 -- Michal Hocko SUSE Labs