From: Arkadiusz Miskiewicz Subject: Re: [PATCH] mm, oom: report compaction/migration stats for higher order requests Date: Sun, 21 Aug 2016 23:19:50 +0200 Message-ID: <201608212319.51001.a.miskiewicz@gmail.com> References: <201608120901.41463.a.miskiewicz@gmail.com> <201608182049.42261.a.miskiewicz@gmail.com> <809abac0-961d-9cc1-ce6b-3227ffc791c7@suse.cz> Reply-To: arekm@maven.pl Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: Michal Hocko , linux-ext4@vger.kernel.org, linux-mm@kvack.org, Jan Kara , Joonsoo Kim To: Vlastimil Babka Return-path: In-Reply-To: <809abac0-961d-9cc1-ce6b-3227ffc791c7@suse.cz> Sender: owner-linux-mm@kvack.org List-Id: linux-ext4.vger.kernel.org On Friday 19 of August 2016, Vlastimil Babka wrote: > On 08/18/2016 08:49 PM, Arkadiusz Miskiewicz wrote: > > On Wednesday 17 of August 2016, Michal Hocko wrote: > >> On Wed 17-08-16 10:34:54, Arkadiusz Mi=C5=9Bkiewicz wrote: > >> [...] > >>=20 > >>> With "[PATCH] mm, oom: report compaction/migration stats for higher > >>> order requests" patch: > >>> https://ixion.pld-linux.org/~arekm/p2/ext4/log-20160817.txt > >>>=20 > >>> Didn't count much - all counters are 0 > >>> compaction_stall:0 compaction_fail:0 compact_migrate_scanned:0 > >>> compact_free_scanned:0 compact_isolated:0 pgmigrate_success:0 > >>> pgmigrate_fail:0 > >>=20 > >> Dohh, COMPACTION counters are events and those are different than other > >> counters we have. They only have per-cpu representation and so we would > >> have to do > >> + for_each_online_cpu(cpu) { > >> + struct vm_event_state *this =3D &per_cpu(vm_event_stat= es, > >> cpu); + ret +=3D this->event[item]; > >> + } > >>=20 > >> which is really nasty because, strictly speaking, we would have to do > >> {get,put}_online_cpus around that loop and that uses locking and we do > >> not want to possibly block in this path just because something is in t= he > >> middle of the hotplug. So let's scratch that patch for now and sorry I > >> haven't realized that earlier. > >>=20 > >>> two processes were killed by OOM (rm and cp), the rest of rm/cp didn't > >>> finish > >>>=20 > >>> and I'm interrupting it to try that next patch: > >>>> Could you try to test with > >>>> patch from > >>>> http://lkml.kernel.org/r/20160816031222.GC16913@js1304-P5Q-DELUXE > >>>> please? Ideally on top of linux-next. You can add both the compaction > >>>> counters patch in the oom report and high order atomic reserves patch > >>>> on top. > >>>=20 > >>> Uhm, was going to use it on top of 4.7.[01] first. > >>=20 > >> OK > >=20 > > So with=20 > > http://lkml.kernel.org/r/20160816031222.GC16913@js1304-P5Q-DELUXE OOM no > > longer happens (all 10x rm/cp processes finished). >=20 > Is it on top of 4.7 then?=20 Yes, it was on top of 4.7.0. > That's a bit different from the other reporter > who needed both linux-next and this patch to avoid OOM. > In any case the proper solution should restrict this disabled heuristic > to highest compaction priority, which needs the patches from linux-next > anyway. >=20 > So can you please also try linux-next with the patch from > http://marc.info/?l=3Dlinux-mm&m=3D147158805719821 ? https://ixion.pld-linux.org/~arekm/p2/ext4/log-20160819.txt https://ixion.pld-linux.org/~arekm/p2/ext4/log-trace_pipe-20160819.txt.gz rm/cp -al x10 succeeded without any OOM so the question is - which solution is "the one" for stable/4.7.x ? Thanks >=20 > Thanks! >=20 > > https://ixion.pld-linux.org/~arekm/p2/ext4/log-20160818.txt > >=20 > > On Wednesday 17 of August 2016, Jan Kara wrote: > >> Just one more debug idea to add on top of what Michal said: Can you > >> enable mm_shrink_slab_start and mm_shrink_slab_end tracepoints (via > >> /sys/kernel/debug/tracing/events/vmscan/mm_shrink_slab_{start,end}/ena= bl > >> e) and gather output from /sys/kernel/debug/tracing/trace_pipe while t= he > >> copy is running? > >=20 > > Here it is: > >=20 > > https://ixion.pld-linux.org/~arekm/p2/ext4/log-trace_pipe-20160818.txt.= gz =2D-=20 Arkadiusz Mi=C5=9Bkiewicz, arekm / ( maven.pl | pld-linux.org ) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org