On Wed, 2019-08-28 at 14:17 -0700, Edward Chron wrote: > On Wed, Aug 28, 2019 at 1:18 PM Qian Cai <cai@xxxxxx> 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.
