Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Mon, 9 May 2022 13:48:39 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     CGEL <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 <yang.yang29@zte.com.cn>
Subject: Re: [PATCH] mm/memcg: support control THP behaviour in cgroup
Message-ID: <Ynj/l+pyFJxKfcbQ@dhcp22.suse.cz>
References: <20220505033814.103256-1-xu.xin16@zte.com.cn>
 <YnUlntNFR4zeD+qa@dhcp22.suse.cz>
 <6275d3e7.1c69fb81.1d62.4504@mx.google.com>
 <YnjmPAToTR0C5o8x@dhcp22.suse.cz>
 <6278fa75.1c69fb81.9c598.f794@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6278fa75.1c69fb81.9c598.f794@mx.google.com>
Precedence: bulk

On Mon 09-05-22 11:26:43, CGEL wrote:
> On Mon, May 09, 2022 at 12:00:28PM +0200, Michal Hocko wrote:
> > 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).
> >
> 
> The cgroup THP behavior is align to host and totally independent just likes
> /sys/fs/cgroup/memory.swappiness. That means if one cgroup config 'always'
> for thp, it has no matter with host or other cgroup. This make it simple for
> user to understand or control.

All controls in cgroup v2 should be hierarchical. This is really
required for a proper delegation semantic.

> If memcg policy madivise but application says never, just like host, the result
> is no THP for that application.
> 
> > > 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.
> 
> At least on some 5G(communication technology) machine, it's useful to provide
> THP based QoS. Those 5G machine use micro-service software architecture, in
> other words one service application runs in one container.

I am not really sure I understand. If this is one application per
container (cgroup) then why do you really need per-group setting?
Does the application is a set of different processes which are only very
loosely tight?

> Container becomes
> the suitable management unit but not the whole host. And some performance
> sensitive containers desiderate THP to provide low latency communication.
> But if we use THP with 'always', it will consume more memory(on our machine
> that is about 10% of total memory). And unnecessary huge pages will increase
> memory pressure, add latency for minor pages faults, and add overhead when
> splitting huge pages or coalescing normal sized pages into huge pages.

It is still not really clear to me how do you achieve that the whole
workload in the said container has the same THP requirements.
-- 
Michal Hocko
SUSE Labs