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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FDFBC433EF for ; Fri, 6 May 2022 13:42:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1441868AbiEFNps (ORCPT ); Fri, 6 May 2022 09:45:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1441886AbiEFNpg (ORCPT ); Fri, 6 May 2022 09:45:36 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA3A538DAB; Fri, 6 May 2022 06:41:53 -0700 (PDT) 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> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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