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 6A5B3C433F5 for ; Mon, 9 May 2022 10:00:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F37986B0073; Mon, 9 May 2022 06:00:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE8A36B0074; Mon, 9 May 2022 06:00:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAFBE6B0075; Mon, 9 May 2022 06:00:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CC2ED6B0073 for ; Mon, 9 May 2022 06:00:35 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9D19621036 for ; Mon, 9 May 2022 10:00:35 +0000 (UTC) X-FDA: 79445760030.15.65FF676 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf16.hostedemail.com (Postfix) with ESMTP id DBC5418009B for ; Mon, 9 May 2022 10:00:26 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B098321C1C; Mon, 9 May 2022 10:00:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1652090433; 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=EnVbGbF3CiTcycSBZO/loerdaCBwAlV6olMPMO9R0Qs=; b=crXHB0LGP0sk30wzd0kWaM5SpjARbCCh70lfRoTsVFXEIuaZcoMvyMb1tID3C62z31gqYe yQ7D8QfaK+pJpNbEPL+K5d78N02gEkqfCsXBVAgUwGGbsSMibVYHliBh+Lr3X45ftFpA+w keJFS3J/goZuc+Z0vjcFJEU3EQEGDXE= 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 0B1902C141; Mon, 9 May 2022 10:00:31 +0000 (UTC) Date: Mon, 9 May 2022 12:00:28 +0200 From: Michal Hocko To: CGEL Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, willy@infradead.org, shy828301@gmail.com, roman.gushchin@linux.dev, shakeelb@google.com, linmiaohe@huawei.com, william.kucharski@oracle.com, peterx@redhat.com, hughd@google.com, vbabka@suse.cz, songmuchun@bytedance.com, surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, Yang Yang Subject: Re: [PATCH] mm/memcg: support control THP behaviour in cgroup Message-ID: References: <20220505033814.103256-1-xu.xin16@zte.com.cn> <6275d3e7.1c69fb81.1d62.4504@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6275d3e7.1c69fb81.1d62.4504@mx.google.com> X-Rspamd-Queue-Id: DBC5418009B X-Stat-Signature: aqi3tqtagxuqo8qkwjjpky6tpfqcsagw X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=crXHB0LG; spf=pass (imf16.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-Rspamd-Server: rspam09 X-HE-Tag: 1652090426-576777 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 Sat 07-05-22 02:05:25, CGEL wrote: [...] > If there are many containers to run on one host, and some of them have high > performance requirements, administrator could turn on thp for them: > # docker run -it --thp-enabled=always > Then all the processes in those containers will always use thp. > While other containers turn off thp by: > # docker run -it --thp-enabled=never I do not know. The THP config space is already too confusing and complex and this just adds on top. E.g. is the behavior of the knob hierarchical? What is the policy if parent memcg says madivise while child says always? How does the per-application configuration aligns with all that (e.g. memcg policy madivise but application says never via prctl while still uses some madvised - e.g. via library). > By doing this we could promote important containers's performance with less > footprint of thp. Do we really want to provide something like THP based QoS? To me it sounds like a bad idea and if the justification is "it might be useful" then I would say no. So you really need to come with a very good usecase to promote this further. -- Michal Hocko SUSE Labs