On Thu 28-04-16 17:45:23, Aaron Lu wrote: > On 04/28/2016 04:57 PM, Michal Hocko wrote: > > On Thu 28-04-16 13:17:08, Aaron Lu wrote: [...] > >> I have the same doubt too, but the results look really stable(only for > >> commit 0da9597ac9c0, see below for more explanation). > > > > I cannot seem to find this sha1. Where does it come from? linux-next? > > Neither can I... > The commit should come from 0day Kbuild service I suppose, which is a > robot to do automatic fetch/building etc. > Could it be that the commit appeared in linux-next some day and then > gone? This wouldn't be unusual because mmotm part of the linux next is constantly rebased. [...] > > OK, so we have 96G for consumers with 32G RAM and 96G of swap space, > > right? That would suggest they should fit in although the swapout could > > be large (2/3 of the faulted memory) and the random pattern can cause > > some trashing. Does the system bahave the same way with the stream anon > > load? Anyway I think we should be able to handle such load, although it > > By stream anon load, do you mean continuous write, without read? Yes > > is quite untypical from my experience because it can be pain with a slow > > swap but ramdisk swap should be as fast as it can get so the swap in/out > > should be basically noop. > > > >> So I guess the question here is, after the OOM rework, is the OOM > >> expected for such a case? If so, then we can ignore this report. > > > > Could you post the OOM reports please? I will try to emulate a similar > > load here as well. > > I attached the dmesg from one of the runs. [...] > [ 77.434044] slabinfo invoked oom-killer: gfp_mask=0x26040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), order=2, oom_score_adj=0 [...] > [ 138.090480] kthreadd invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2, oom_score_adj=0 [...] > [ 141.823925] lkp-setup-rootf invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2, oom_score_adj=0 All of them are order-2 and this was a known problem for "mm, oom: rework oom detection" commit and later should make it much more resistant to failures for higher (!costly) orders. So I would definitely encourage you to retest with the current _complete_ mmotm tree. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>