All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: CGEL <cgel.zte@gmail.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>,
	Shakeel Butt <shakeelb@google.com>,
	Yang Shi <shy828301@gmail.com>, Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Matthew Wilcox <willy@infradead.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	William Kucharski <william.kucharski@oracle.com>,
	Peter Xu <peterx@redhat.com>, Hugh Dickins <hughd@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Muchun Song <songmuchun@bytedance.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>, Cgroups <cgroups@vger.kernel.org>,
	Yang Yang <yang.yang29@zte.com.cn>
Subject: Re: [PATCH] mm/memcg: support control THP behaviour in cgroup
Date: Wed, 18 May 2022 18:14:45 +1000	[thread overview]
Message-ID: <YoSq9W995QPM6tWQ@balbir-desktop> (raw)
In-Reply-To: <627b2df5.1c69fb81.4a22.160f@mx.google.com>

On Wed, May 11, 2022 at 03:31:00AM +0000, CGEL wrote:
> On Tue, May 10, 2022 at 08:11:16PM -0700, Roman Gushchin wrote:
> > On Tue, May 10, 2022 at 07:47:29PM -0700, Shakeel Butt wrote:
> > > On Tue, May 10, 2022 at 7:19 PM CGEL <cgel.zte@gmail.com> wrote:
> > > >
> > > [...]
> > > > > > >
> > > > > > > All controls in cgroup v2 should be hierarchical. This is really
> > > > > > > required for a proper delegation semantic.
> > > > > > >
> > > > > >
> > > > > > Could we align to the semantic of /sys/fs/cgroup/memory.swappiness?
> > > > > > Some distributions like Ubuntu is still using cgroup v1.
> > > > >
> > > > > Other than enable flag, how would you handle the defrag flag
> > > > > hierarchically? It is much more complicated.
> > > >
> > > > Refer to memory.swappiness for cgroup, this new interface better be independent.
> > > 
> > > Let me give my 0.02. I buy the use-case of Admin restricting THPs to
> > > low priority jobs but I don't think memory controller is the right
> > > place to enforce that policy. Michal gave one way (prctl()) to enforce
> > > that policy. Have you explored the BPF way to enforce this policy?
> > 
> > +1 for bpf
> > 
> > I think these THP hints are too implementation-dependent and unstable to become
> > a part of cgroup API.
> >
> 
> Thanks! If no other suggesting we will submit a bpf version of this patch.
>

What is your proposal for BPF? How do you intend to add attach points
(attach_type) for policy? Is it still going to be per cgroup?

Balbir Singh

WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: CGEL <cgel.zte-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Roman Gushchin
	<roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>,
	Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Yang Shi <shy828301-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	William Kucharski
	<william.kucharski-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Peter Xu <peterx-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>,
	Muchun Song <songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
	Suren Baghdasaryan
	<surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Yang Yang <yang.yang29-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.org>
Subject: Re: [PATCH] mm/memcg: support control THP behaviour in cgroup
Date: Wed, 18 May 2022 18:14:45 +1000	[thread overview]
Message-ID: <YoSq9W995QPM6tWQ@balbir-desktop> (raw)
In-Reply-To: <627b2df5.1c69fb81.4a22.160f-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>

On Wed, May 11, 2022 at 03:31:00AM +0000, CGEL wrote:
> On Tue, May 10, 2022 at 08:11:16PM -0700, Roman Gushchin wrote:
> > On Tue, May 10, 2022 at 07:47:29PM -0700, Shakeel Butt wrote:
> > > On Tue, May 10, 2022 at 7:19 PM CGEL <cgel.zte-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > [...]
> > > > > > >
> > > > > > > All controls in cgroup v2 should be hierarchical. This is really
> > > > > > > required for a proper delegation semantic.
> > > > > > >
> > > > > >
> > > > > > Could we align to the semantic of /sys/fs/cgroup/memory.swappiness?
> > > > > > Some distributions like Ubuntu is still using cgroup v1.
> > > > >
> > > > > Other than enable flag, how would you handle the defrag flag
> > > > > hierarchically? It is much more complicated.
> > > >
> > > > Refer to memory.swappiness for cgroup, this new interface better be independent.
> > > 
> > > Let me give my 0.02. I buy the use-case of Admin restricting THPs to
> > > low priority jobs but I don't think memory controller is the right
> > > place to enforce that policy. Michal gave one way (prctl()) to enforce
> > > that policy. Have you explored the BPF way to enforce this policy?
> > 
> > +1 for bpf
> > 
> > I think these THP hints are too implementation-dependent and unstable to become
> > a part of cgroup API.
> >
> 
> Thanks! If no other suggesting we will submit a bpf version of this patch.
>

What is your proposal for BPF? How do you intend to add attach points
(attach_type) for policy? Is it still going to be per cgroup?

Balbir Singh

  reply	other threads:[~2022-05-18  8:14 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05  3:38 [PATCH] mm/memcg: support control THP behaviour in cgroup cgel.zte
2022-05-05  3:38 ` cgel.zte-Re5JQEeQqe8AvxtiuMwx3w
2022-05-05 12:49 ` kernel test robot
2022-05-05 12:49   ` kernel test robot
2022-05-05 13:31 ` kernel test robot
2022-05-05 13:31   ` kernel test robot
2022-05-05 16:09 ` kernel test robot
2022-05-05 16:09   ` kernel test robot
2022-05-06 13:41 ` Michal Hocko
2022-05-06 13:41   ` Michal Hocko
2022-05-07  2:05   ` CGEL
2022-05-07  2:05     ` CGEL
2022-05-09 10:00     ` Michal Hocko
2022-05-09 10:00       ` Michal Hocko
2022-05-09 11:26       ` CGEL
2022-05-09 11:26         ` CGEL
2022-05-09 11:48         ` Michal Hocko
2022-05-09 11:48           ` Michal Hocko
2022-05-10  1:43           ` CGEL
2022-05-10  1:43             ` CGEL
2022-05-10 10:00             ` Michal Hocko
2022-05-10 10:00               ` Michal Hocko
2022-05-10 11:52               ` CGEL
2022-05-10 11:52                 ` CGEL
2022-05-10 13:36                 ` Michal Hocko
2022-05-10 13:36                   ` Michal Hocko
2022-05-11  1:59                   ` CGEL
2022-05-11  1:59                     ` CGEL
2022-05-11  7:21                     ` Michal Hocko
2022-05-11  7:21                       ` Michal Hocko
2022-05-11  9:47                       ` CGEL
2022-05-18  5:58                   ` CGEL
2022-05-18  5:58                     ` CGEL
2022-05-10 19:34             ` Yang Shi
2022-05-10 19:34               ` Yang Shi
2022-05-11  2:19               ` CGEL
2022-05-11  2:19                 ` CGEL
2022-05-11  2:47                 ` Shakeel Butt
2022-05-11  2:47                   ` Shakeel Butt
2022-05-11  3:11                   ` Roman Gushchin
2022-05-11  3:11                     ` Roman Gushchin
2022-05-11  3:31                     ` CGEL
2022-05-11  3:31                       ` CGEL
2022-05-18  8:14                       ` Balbir Singh [this message]
2022-05-18  8:14                         ` Balbir Singh
2022-05-11  3:17                   ` CGEL
2022-05-11  3:17                     ` CGEL

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YoSq9W995QPM6tWQ@balbir-desktop \
    --to=bsingharora@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgel.zte@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=peterx@redhat.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=songmuchun@bytedance.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=william.kucharski@oracle.com \
    --cc=willy@infradead.org \
    --cc=yang.yang29@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.