On Fri, Aug 03, 2018 at 01:30:49PM -0700, Roman Gushchin wrote: > On Fri, Aug 03, 2018 at 10:57:43AM -0700, Tejun Heo wrote: > > + seq_pr_info(m, "pgfault %lu\n", events[PGFAULT]); > > + seq_pr_info(m, "pgmajfault %lu\n", events[PGMAJFAULT]); > > + > > + seq_pr_info(m, "pgrefill %lu\n", events[PGREFILL]); > > + seq_pr_info(m, "pgscan %lu\n", events[PGSCAN_KSWAPD] + > > + events[PGSCAN_DIRECT]); > > + seq_pr_info(m, "pgsteal %lu\n", events[PGSTEAL_KSWAPD] + > > + events[PGSTEAL_DIRECT]); > > + seq_pr_info(m, "pgactivate %lu\n", events[PGACTIVATE]); > > + seq_pr_info(m, "pgdeactivate %lu\n", events[PGDEACTIVATE]); > > + seq_pr_info(m, "pglazyfree %lu\n", events[PGLAZYFREE]); > > + seq_pr_info(m, "pglazyfreed %lu\n", events[PGLAZYFREED]); > > > > + seq_pr_info(m, "workingset_refault %lu\n", > > + stat[WORKINGSET_REFAULT]); > > + seq_pr_info(m, "workingset_activate %lu\n", > > + stat[WORKINGSET_ACTIVATE]); > > + seq_pr_info(m, "workingset_nodereclaim %lu\n", > > + stat[WORKINGSET_NODERECLAIM]); > > I'm not sure we need all theses stats in the oom report. > I'd drop the events part. This info dump usually races with ongoing reclaim and frees. The VM state might have changed quite a bit by the time this is all written out, which sometimes makes it hard to rootcause from just the state snapshots. Knowing what the VM was doing before the OOM is helpful. I'd prefer we keep those in. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
