Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390064 > unrolled thread

Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput -11.8% regression

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput  -11.8% regression Michal Hocko <mhocko@kernel.org> - 2016-04-28 13:30 +0200
    Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput  -11.8% regression Aaron Lu <aaron.lu@intel.com> - 2016-04-29 11:00 +0200
      Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput  -11.8% regression Michal Hocko <mhocko@kernel.org> - 2016-04-29 11:30 +0200
        Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput  -11.8% regression Aaron Lu <aaron.lu@intel.com> - 2016-04-29 15:00 +0200
          Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput  -11.8% regression Michal Hocko <mhocko@kernel.org> - 2016-04-29 15:10 +0200

#1390064 — Re: [LKP] [lkp] [mm, oom] faad2185f4: vm-scalability.throughput -11.8% regression

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

[toc] | [next] | [standalone]

#1390885

On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> 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.

OK, will run the test on this branch:
https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git since-4.5
with head commit:
commit 81cc2e6f1e8bd81ebc7564a3cd3797844ee1712e
Author: Michal Hocko <mhocko@suse.com>
Date:   Thu Apr 28 12:03:24 2016 +0200

    drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable

Please let me know if this isn't right.

[toc] | [prev] | [next] | [standalone]

#1390927

On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > 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.
> 
> OK, will run the test on this branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git since-4.5
> with head commit:
> commit 81cc2e6f1e8bd81ebc7564a3cd3797844ee1712e
> Author: Michal Hocko <mhocko@suse.com>
> Date:   Thu Apr 28 12:03:24 2016 +0200
> 
>     drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable
> 
> Please let me know if this isn't right.

Yes that should contain all the oom related patches in the mmotm tree.

Thanks!

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1391094

On Fri, Apr 29, 2016 at 11:29:36AM +0200, Michal Hocko wrote:
> On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> > On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > > 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.
> > 
> > OK, will run the test on this branch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git since-4.5
> > with head commit:
> > commit 81cc2e6f1e8bd81ebc7564a3cd3797844ee1712e
> > Author: Michal Hocko <mhocko@suse.com>
> > Date:   Thu Apr 28 12:03:24 2016 +0200
> > 
> >     drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable
> > 
> > Please let me know if this isn't right.
> 
> Yes that should contain all the oom related patches in the mmotm tree.

The test shows commit 81cc2e6f1e doesn't OOM anymore and its throughput 
is 43609, the same level compared to 43802, so everyting is fine :-)

[toc] | [prev] | [next] | [standalone]

#1391116

On Fri 29-04-16 20:54:13, Aaron Lu wrote:
> On Fri, Apr 29, 2016 at 11:29:36AM +0200, Michal Hocko wrote:
> > On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> > > On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > > > 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.
> > > 
> > > OK, will run the test on this branch:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git since-4.5
> > > with head commit:
> > > commit 81cc2e6f1e8bd81ebc7564a3cd3797844ee1712e
> > > Author: Michal Hocko <mhocko@suse.com>
> > > Date:   Thu Apr 28 12:03:24 2016 +0200
> > > 
> > >     drm/amdgpu: make amdgpu_mn_get wait for mmap_sem killable
> > > 
> > > Please let me know if this isn't right.
> > 
> > Yes that should contain all the oom related patches in the mmotm tree.
> 
> The test shows commit 81cc2e6f1e doesn't OOM anymore and its throughput 
> is 43609, the same level compared to 43802, so everyting is fine :-)

Thanks a lot for double checking! This is highly appreciated!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web