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 E819AC433F5 for ; Fri, 6 May 2022 13:41:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 352966B0072; Fri, 6 May 2022 09:41:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3011B6B0073; Fri, 6 May 2022 09:41:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F1566B0074; Fri, 6 May 2022 09:41:55 -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 11BD06B0072 for ; Fri, 6 May 2022 09:41:55 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id D6F9B810E5 for ; Fri, 6 May 2022 13:41:54 +0000 (UTC) X-FDA: 79435431348.17.40BAE2F Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf13.hostedemail.com (Postfix) with ESMTP id 3E82720009 for ; Fri, 6 May 2022 13:41:40 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 5D55F1F91C; Fri, 6 May 2022 13:41:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1651844512; 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=pXZ/Mip46MPK94udG6dn0vA9jCul4KfitQH0YKOCKlo=; b=VV80UgGUua9ByI5dnKDgazpxk/aupgxGDKd9KoBkpD9krA/NR1XXVh6kgSKaZ7FUzsf8f0 zkBRcq08cNuw+WGzG+8vRnfHpT3IQstg+wTRO7clRbPhs6BBEHLo0KCBFeEKzSE5o9Tl3z hIkEaaxexMDzsfw5D/nqLKWqnK7j/Zw= 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 1D7312C142; Fri, 6 May 2022 13:41:51 +0000 (UTC) Date: Fri, 6 May 2022 15:41:50 +0200 From: Michal Hocko To: cgel.zte@gmail.com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220505033814.103256-1-xu.xin16@zte.com.cn> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3E82720009 X-Stat-Signature: ohnz4oo7ehiak9b7yoeqouy8bacamb77 X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VV80UgGU; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1651844500-719879 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 05-05-22 03:38:15, cgel.zte@gmail.com wrote: > From: Yang Yang > > Using THP may promote the performance of memory, but increase memory > footprint. Applications may use madvise to decrease footprint, but > not all applications support using madvise, and it takes much costs > to re-code all the applications. And we notice container becomes more > and more popular to manage a set of tasks. Could you be more specific about the actual usecase? When do you group processes based on their general THP reqirements? You are mentioning containers but those are usually bags of different processes that just share a common objective. > So add support for cgroup to control THP behaviour will provide much > convenience, administrator may only enable THP for important containers, > and disable it for other containers. Why would that be a matter of importance? Also what is actual semantic when processes living inside those cgroups explicitly state their THP requirements? -- Michal Hocko SUSE Labs