[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231129123446.7d41c4e9@gandalf.local.home>
Date: Wed, 29 Nov 2023 12:34:46 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Michal Hocko <mhocko@...e.com>
Cc: Dmitry Rokosov <ddrokosov@...utedevices.com>,
akpm@...ux-foundation.org, mhiramat@...nel.org, hannes@...xchg.org,
roman.gushchin@...ux.dev, shakeelb@...gle.com,
muchun.song@...ux.dev, kernel@...rdevices.ru, rockosov@...il.com,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v3 2/2] mm: memcg: introduce new event to trace
shrink_memcg
On Wed, 29 Nov 2023 18:10:33 +0100
Michal Hocko <mhocko@...e.com> wrote:
> > > How? You are only reporting the number of reclaimed pages and no
> > > reclaimed pages could be not just because of low/min limits but
> > > generally because of other reasons. You would need to report also the
> > > number of scanned/isolated pages.
> > >
> >
> > From my perspective, if memory control group (memcg) protection
> > restrictions occur, we can identify them by the absence of the end()
> > pair of begin(). Other reasons will have both tracepoints raised.
>
> That is not really great way to detect that TBH. Trace events could be
> lost and then you simply do not know what has happened.
Note, you can detect dropped events. If there's a dropped event, you can
ignore the "missing end" from a beginning. You could also make synthetic
events that pair an end event with a beginning event (which uses the last
begin event found). Synthetic event creation is not affected by dropped
events.
There's a lot you can to get information with the prospect of dropped
events. I would not use that as rationale for not using events.
-- Steve
Powered by blists - more mailing lists