From: Dmitry Rokosov <ddrokosov@salutedevices.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: <hannes@cmpxchg.org>, <mhocko@kernel.org>,
<roman.gushchin@linux.dev>, <shakeelb@google.com>,
<muchun.song@linux.dev>, <akpm@linux-foundation.org>,
<kernel@sberdevices.ru>, <rockosov@gmail.com>,
<cgroups@vger.kernel.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, <bpf@vger.kernel.org>
Subject: Re: [PATCH v1] tools/cgroup: introduce cgroup v2 memory.events listener
Date: Wed, 1 Nov 2023 21:07:33 +0300 [thread overview]
Message-ID: <20231101180733.ok7j34izehrpyfpy@CAB-WSD-L081021> (raw)
In-Reply-To: <eqvaejfo5uoz5m7e5g3wjgegfo4ribajdgu57fst3hu5m6gfa4@beugaul6pjjz>
Hello Michal,
Thank you for the feedback!
On Wed, Nov 01, 2023 at 04:56:47PM +0100, Michal Koutný wrote:
> Hi.
>
> I think the tools/cgroup/cgroup_event_listener.c was useful in the past
> to demonstrate the non-traditional API of cgroup.event_control with FDs
> passing left and right.
>
>
> On Fri, Oct 13, 2023 at 09:41:07PM +0300, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
> > This is a simple listener for memory events that handles counter
> > changes in runtime. It can be set up for a specific memory cgroup v2.
>
> Event files on v2 are based on more standard poll or inotify APIs so
> they don't need such a (cgroup specific) demo. Additionally, the demo
> program lists individual events, so it'd be a maintenance burden to keep
> them in sync with the kernel implementation.
From my perspective, eventfd serves as the standard mechanism as well.
Therefore, when incorporating the cgroup v1 event listener test into my
project, I initially turned to the tools example, which proved to be
immensely beneficial. Conversely, the cgroup v2 inotify example can
solely be found within the kernel selftests. Although the prevalence of
inotify makes this somewhat understandable, having an additional example
would provide supplementary documentation, which is often invaluable to
developers operating in userspace. Of course, there are maintenance
expenses associated with this approach, as you rightly pointed out.
However, I am willing to undertake the responsibility of maintaining
this example if necessary.
--
Thank you,
Dmitry
next prev parent reply other threads:[~2023-11-01 18:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 18:41 Dmitry Rokosov
2023-11-01 10:43 ` Dmitry Rokosov
2023-11-01 15:56 ` Michal Koutný
2023-11-01 18:07 ` Dmitry Rokosov [this message]
2023-11-06 22:09 ` Andrew Morton
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=20231101180733.ok7j34izehrpyfpy@CAB-WSD-L081021 \
--to=ddrokosov@salutedevices.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel@sberdevices.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=rockosov@gmail.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox