From: Qian Cai <cai@lca.pw>
To: Edward Chron <echron@arista.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Rientjes <rientjes@google.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Shakeel Butt <shakeelb@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Ivan Delalande <colona@arista.com>
Subject: Re: [PATCH 00/10] OOM Debug print selection and additional information
Date: Wed, 28 Aug 2019 17:34:50 -0400 [thread overview]
Message-ID: <1567028090.5576.21.camel@lca.pw> (raw)
In-Reply-To: <CAM3twVQ_J77-yxg+cakUJy9-oZw+j-9xdunaAJdJdfZfCb5GSA@mail.gmail.com>
On Wed, 2019-08-28 at 14:17 -0700, Edward Chron wrote:
> On Wed, Aug 28, 2019 at 1:18 PM Qian Cai <cai@lca.pw> wrote:
> >
> > On Wed, 2019-08-28 at 12:46 -0700, Edward Chron wrote:
> > > But with the caveat that running a eBPF script that it isn't standard
> > > Linux
> > > operating procedure, at this point in time any way will not be well
> > > received in the data center.
> >
> > Can't you get your eBPF scripts into the BCC project? As far I can tell, the
> > BCC
> > has been included in several distros already, and then it will become a part
> > of
> > standard linux toolkits.
> >
> > >
> > > Our belief is if you really think eBPF is the preferred mechanism
> > > then move OOM reporting to an eBPF.
> > > I mentioned this before but I will reiterate this here.
> >
> > On the other hand, it seems many people are happy with the simple kernel OOM
> > report we have here. Not saying the current situation is perfect. On the top
> > of
> > that, some people are using kdump, and some people have resource monitoring
> > to
> > warn about potential memory overcommits before OOM kicks in etc.
>
> Assuming you can implement your existing report in eBPF then those who like
> the
> current output would still get the current output. Same with the patches we
> sent
> upstream, nothing in the report changes by default. So no problems for those
> who
> are happy, they'll still be happy.
I don't think it makes any sense to rewrite the existing code to depends on eBPF
though.
next prev parent reply other threads:[~2019-08-28 21:34 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 19:36 [PATCH 00/10] OOM Debug print selection and additional information Edward Chron
2019-08-26 19:36 ` [PATCH 01/10] mm/oom_debug: Add Debug base code Edward Chron
2019-08-27 13:28 ` kbuild test robot
2019-08-26 19:36 ` [PATCH 02/10] mm/oom_debug: Add System State Summary Edward Chron
2019-08-26 19:36 ` [PATCH 03/10] mm/oom_debug: Add Tasks Summary Edward Chron
2019-08-26 19:36 ` [PATCH 04/10] mm/oom_debug: Add ARP and ND Table Summary usage Edward Chron
2019-08-26 19:36 ` [PATCH 05/10] mm/oom_debug: Add Select Slabs Print Edward Chron
2019-08-26 19:36 ` [PATCH 06/10] mm/oom_debug: Add Select Vmalloc Entries Print Edward Chron
2019-08-26 19:36 ` [PATCH 07/10] mm/oom_debug: Add Select Process " Edward Chron
2019-08-26 19:36 ` [PATCH 08/10] mm/oom_debug: Add Slab Select Always Print Enable Edward Chron
2019-08-26 19:36 ` [PATCH 09/10] mm/oom_debug: Add Enhanced Slab Print Information Edward Chron
2019-08-26 19:36 ` [PATCH 10/10] mm/oom_debug: Add Enhanced Process " Edward Chron
2019-08-28 0:21 ` kbuild test robot
2019-08-27 7:15 ` [PATCH 00/10] OOM Debug print selection and additional information Michal Hocko
2019-08-27 10:10 ` Tetsuo Handa
2019-08-27 10:38 ` Michal Hocko
2019-08-28 1:07 ` Edward Chron
2019-08-28 6:59 ` Michal Hocko
2019-08-28 19:46 ` Edward Chron
2019-08-28 20:18 ` Qian Cai
2019-08-28 21:17 ` Edward Chron
2019-08-28 21:34 ` Qian Cai [this message]
2019-08-29 7:11 ` Michal Hocko
2019-08-29 10:14 ` Tetsuo Handa
2019-08-29 11:56 ` Michal Hocko
2019-08-29 14:09 ` Tetsuo Handa
2019-08-29 15:48 ` Edward Chron
2019-08-29 15:03 ` Edward Chron
2019-08-29 15:42 ` Qian Cai
2019-08-29 16:09 ` Edward Chron
2019-08-29 18:44 ` Qian Cai
2019-08-29 22:41 ` Edward Chron
2019-08-29 16:17 ` Michal Hocko
2019-08-29 16:35 ` Edward Chron
2019-08-29 15:20 ` Edward Chron
2019-08-27 12:40 ` Qian Cai
2019-08-28 0:23 ` Edward Chron
2019-08-28 0:50 ` Qian Cai
2019-08-28 1:13 ` Edward Chron
2019-08-28 1:32 ` Qian Cai
2019-08-28 2:47 ` Edward Chron
2019-08-28 7:08 ` Michal Hocko
2019-08-28 10:12 ` Tetsuo Handa
2019-08-28 10:32 ` Michal Hocko
2019-08-28 10:56 ` Tetsuo Handa
2019-08-28 11:12 ` Michal Hocko
2019-08-28 20:04 ` Edward Chron
2019-08-29 3:31 ` Edward Chron
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=1567028090.5576.21.camel@lca.pw \
--to=cai@lca.pw \
--cc=akpm@linux-foundation.org \
--cc=colona@arista.com \
--cc=echron@arista.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rientjes@google.com \
--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 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.