Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1561320
| From | Trevor Cordes <trevor@tecnopolis.ca> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected) |
| Date | 2017-01-18 08:00 +0100 |
| Message-ID | <t0SnT-HV-1@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <sYq2K-6QF-13@gated-at.bofh.it> <sYA25-4n7-11@gated-at.bofh.it> <sYK1s-2hi-23@gated-at.bofh.it> <sZMDT-7Go-1@gated-at.bofh.it> <t0dkL-817-33@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2017-01-16 Mel Gorman wrote: > > > You can easily check whether this is memcg related by trying to > > > run the same workload with cgroup_disable=memory kernel command > > > line parameter. This will put all the memcg specifics out of the > > > way. > > > > I will try booting now into cgroup_disable=memory to see if that > > helps at all. I'll reply back in 48 hours, or when it oom's, > > whichever comes first. > > > > Thanks. It has successfully survived 70 hours and 2 3am cycles (when it normally oom's) with your first patch *and* cgroup_disable=memory grafted on Fedora's 4.8.13. Since it has never survived 2 3am cycles, I strongly suspect the cgroup_disable=memory mitigates my bug. > > Also, should I bother trying the latest git HEAD to see if that > > solves anything? Thanks! > > That's worth trying. If that also fails then could you try the > following hack to encourage direct reclaim to reclaim slab when > buffers are over the limit please? > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 532a2a750952..46aac487b89a 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist > *zonelist, struct scan_control *sc) continue; > > if (sc->priority != DEF_PRIORITY && > + !buffer_heads_over_limit && > !pgdat_reclaimable(zone->zone_pgdat)) > continue; /* Let kswapd poll > it */ What's the next best step? HEAD? HEAD + the above patch? A new patch? I'll start a HEAD compile until I hear more. I assume I should test without cgroup_disable=memory as that's just a kludge/workaround, right? Also, is there a way to spot the slab pressure you are talking about before oom's occur? slabinfo? I suppose I'd be able to see some counter slowly getting too high or low? Thanks!
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected) Trevor Cordes <trevor@tecnopolis.ca> - 2017-01-18 08:00 +0100
csiph-web