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 5F633C433EF for ; Fri, 8 Oct 2021 11:55:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EC47B60F6E for ; Fri, 8 Oct 2021 11:55:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EC47B60F6E 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 46DCF6B0072; Fri, 8 Oct 2021 07:55:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41E6B6B0073; Fri, 8 Oct 2021 07:55:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E6376B0074; Fri, 8 Oct 2021 07:55:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id 21B5A6B0072 for ; Fri, 8 Oct 2021 07:55:29 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D04AE8249980 for ; Fri, 8 Oct 2021 11:55:28 +0000 (UTC) X-FDA: 78673115136.06.9ECC1F3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id 691D8200B388 for ; Fri, 8 Oct 2021 11:55:28 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 2C0DC21987; Fri, 8 Oct 2021 11:55:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1633694127; 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=ZQJ68UJF1UZJy1bavpd29rgK/K1ZJathwtfYweveOqM=; b=Z6t2/6psmMNzgiKhQKcUfE8OReafFdlssMrUFTy5W23oQMGG/J33ny0iJvBefQVz/tVk8I RYmoWZ+8M2Aiz0kyave7HeKVnHAdjhfR/0U0uxXq6VPhZnCsYnvZ1OhkJqARe8Bql7cA4S ID5vNM8Qhzta/3XrAzC8capcBahVN8k= 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 106DEA3B84; Fri, 8 Oct 2021 11:55:26 +0000 (UTC) Date: Fri, 8 Oct 2021 13:55:23 +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: rspam01 X-Rspamd-Queue-Id: 691D8200B388 X-Stat-Signature: qoauzg5gf9ru1qbm6ym5ri8gi81zcfgr Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="Z6t2/6ps"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1633694128-508795 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 Fri 08-10-21 17:17:12, Baolin Wang wrote: > > > On 2021/10/8 15:12, Michal Hocko wrote: > > 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? > > Sorry for confusing, what I mean is, when tasks from one hugetlb cgroup are > migrated to a new hugetlb cgroup, the new hugetlb cgroup's hugetlb page > usage is not increased accordingly. Which is a perferctly reasonable behavior as the memory has been consumed from the original cgroup and it will be freed there as well. Migrating to a new cgroup doesn't imply all the resources to be migrated as well. > The issue I found is just from my > testing for the hugetlb cgroup, and I think this is not resonable if we've > already set a hugetlb limitation for a cgroup, but we always ignore it when > tasks migration among hugetlb cgroups. I would like to learn more about why you consider this unreasonable. This will likely depend on the reason why you want/need to migrate task. If you want to move a task to completely new resource domain (read a completely different cgroup subtree) then I can imagine you want to leave all the resources but this will have problems with other resource controllers - e.g. memory cgroup v2 which doesn't allow charge migration either. -- Michal Hocko SUSE Labs