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 33FDFC433EF for ; Fri, 8 Oct 2021 07:12:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BD2D160FD9 for ; Fri, 8 Oct 2021 07:12:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BD2D160FD9 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 0A1D4900002; Fri, 8 Oct 2021 03:12:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 051FD6B0072; Fri, 8 Oct 2021 03:12:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8336900002; Fri, 8 Oct 2021 03:12:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id D73756B0071 for ; Fri, 8 Oct 2021 03:12:18 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8AB101842A001 for ; Fri, 8 Oct 2021 07:12:18 +0000 (UTC) X-FDA: 78672401556.02.B0450DF Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf07.hostedemail.com (Postfix) with ESMTP id 1B5FB1001B23 for ; Fri, 8 Oct 2021 07:12:17 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id ECFAC223D5; Fri, 8 Oct 2021 07:12:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1633677136; 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=9JkoUZpACyUfQpOqubca79HEaq3VBgN30ug9B5nuPpY=; b=NXd7i7CU+nz4qyVPFPKYz5t696OgTmGX9aCZsWZAX/9WpZQe3qtTbwkjr72JDLPBkxpVo1 2sc8ArtAiEM6F8uMI5MwqrIiV6j78/xaxaR7ZR5p3/OJmkt32Ow6EItlWMsXamCrA8k90e cuwA9/KRcP6TNcmmp/2yggBTEet8rOA= Received: from suse.cz (unknown [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 CC92BA3B81; Fri, 8 Oct 2021 07:12:16 +0000 (UTC) Date: Fri, 8 Oct 2021 09:12:16 +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: rspam02 X-Rspamd-Queue-Id: 1B5FB1001B23 X-Stat-Signature: p5f35gygciydp85593szgpnrott4qffd Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=NXd7i7CU; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1633677137-453074 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 Thu 07-10-21 23:39:15, Baolin Wang wrote: > Hi Michal, > > (Sorry for late reply due to my holidays) > On 2021/9/30 18:46, Michal Hocko wrote: > > 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? > > The problems is that, it did not check if the tasks can move to the new > hugetlb cgroup if the new hugetlb cgroup has a limitation, and the hugetlb > cgroup usage is incorrect when moving tasks among hugetlb cgroups. Could you be more specific please? What do you mean by cgroup usage is incorrect? Ideally could you describe your usecase? > > > 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 > > Sorry, I missed this part, could you elaborate on the issues? I can have a > close look about the problems of memcg charge moving. The operation is quite expensive. Synchronization with charging is not trivial. I do not have the full list handy but you can search the mm mailing list archives for more information. > > 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? > > But I think it is reasonable for some cases moving the old charging to the > new cgroup when task migration. Maybe I can add a new hugetlb cgroup file to > control if need this or not? It would be good to describe those use cases and why they really need this. Because as things stand now, the charge migration is not supported in cgroup v2 for memory cgroup controller and there are no plans to add the support so it would be quite unexpected that hugetlb controller would behave differently. And cgroup v1 is considered legacy and new features are ususally not added as there is a hope to move users to v2. -- Michal Hocko SUSE Labs