Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Guenter Roeck]

Hi,

I see a lot of crashes with various architectures in next-20160623.
I bisected mips and sh; both bisect log point to the same patch.
Bisect log is attached. arm, ppc, and x86 images crash as well,
but I did not confirm if the same patch is the culprit there.

I tried to revert the patch, but that did not work due to subsequent patches
affecting the same code.

Guenter

---
# bad: [5c4d1ca9cfa71d9515ce5946cfc6497d22b1108e] Add linux-next specific files for 20160623
# good: [33688abb2802ff3a230bd2441f765477b94cc89e] Linux 4.7-rc4
git bisect start 'HEAD' 'v4.7-rc4'
# good: [0cc6a3a989f351112e1b8534f787b19a125b6281] Merge remote-tracking branch 'drm/drm-next'
git bisect good 0cc6a3a989f351112e1b8534f787b19a125b6281
# good: [72e9d226a2de83374fc66e59955a4d34c34c0c0f] Merge remote-tracking branch 'clockevents/clockevents/next'
git bisect good 72e9d226a2de83374fc66e59955a4d34c34c0c0f
# good: [0d35ad6e1a47d9951249542c90038039730f2cc4] Merge remote-tracking branch 'staging/staging-next'
git bisect good 0d35ad6e1a47d9951249542c90038039730f2cc4
# good: [9b5c3f08e656e53b226c4763a111c85675b1e651] Merge remote-tracking branch 'coresight/next'
git bisect good 9b5c3f08e656e53b226c4763a111c85675b1e651
# good: [760dfb53d9c2a81ef36895a12f7cabdb69cabf54] shmem, thp: respect MADV_{NO,}HUGEPAGE for file mappings
git bisect good 760dfb53d9c2a81ef36895a12f7cabdb69cabf54
# bad: [d664b7e1455775b014abafcf85134573c496e2ef] samples/kprobe: convert the printk to pr_info/pr_err
git bisect bad d664b7e1455775b014abafcf85134573c496e2ef
# good: [692ac72dc26d4735abefdba0876049710d1e57f8] mm, vmscan: add classzone information to tracepoints
git bisect good 692ac72dc26d4735abefdba0876049710d1e57f8
# bad: [78aa21d400775ad5d6df41209369430114c7f56a] proc_oom_score: remove tasklist_lock and pid_alive()
git bisect bad 78aa21d400775ad5d6df41209369430114c7f56a
# bad: [e7a21d36c970ce6506dfbde2e34d773ff492280a] mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj
git bisect bad e7a21d36c970ce6506dfbde2e34d773ff492280a
# bad: [9c22c0aef92a9dd9cead68e4796bb09253a3efb6] thp: fix comments of __pmd_trans_huge_lock()
git bisect bad 9c22c0aef92a9dd9cead68e4796bb09253a3efb6
# bad: [76a3308aea2ccb472eeebdf78dd27590b8ee8541] mm: page_alloc: cache the last node whose dirty limit is reached
git bisect bad 76a3308aea2ccb472eeebdf78dd27590b8ee8541
# bad: [089fcc128177aaa80935ad21d522a5be11007f9c] mm, page_alloc: remove fair zone allocation policy
git bisect bad 089fcc128177aaa80935ad21d522a5be11007f9c
# first bad commit: [089fcc128177aaa80935ad21d522a5be11007f9c] mm, page_alloc: remove fair zone allocation policy

Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Mel Gorman]

On Thu, Jun 23, 2016 at 11:05:33PM -0700, Guenter Roeck wrote:
> Hi,
> 
> I see a lot of crashes with various architectures in next-20160623.
> I bisected mips and sh; both bisect log point to the same patch.
> Bisect log is attached. arm, ppc, and x86 images crash as well,
> but I did not confirm if the same patch is the culprit there.
> 

The series has been dropped. Due to conflicts with other patches, there
were a few bugs introduced, one which potentially corrupted memory. Just
to be sure though, what sort of workload crashed just in case I need to
adjust the test coverage?

-- 
Mel Gorman
SUSE Labs

Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Guenter Roeck]

Hi Mel,

On 06/24/2016 01:39 AM, Mel Gorman wrote:
> On Thu, Jun 23, 2016 at 11:05:33PM -0700, Guenter Roeck wrote:
>> Hi,
>>
>> I see a lot of crashes with various architectures in next-20160623.
>> I bisected mips and sh; both bisect log point to the same patch.
>> Bisect log is attached. arm, ppc, and x86 images crash as well,
>> but I did not confirm if the same patch is the culprit there.
>>
>
> The series has been dropped. Due to conflicts with other patches, there
> were a few bugs introduced, one which potentially corrupted memory. Just
> to be sure though, what sort of workload crashed just in case I need to
> adjust the test coverage?
>

This is just a basic qemu boot test. No workload at all.
Here is a complete list of failures.

Qemu test results:
	total: 107 pass: 66 fail: 41
Failed tests:
	arm:versatilepb-scsi:versatile_defconfig:versatile-pb
	arm:versatileab:versatile_defconfig:versatile-ab
	arm:versatilepb:versatile_defconfig:versatile-pb
	arm:imx25-pdk:imx_v4_v5_defconfig:imx25-pdk
	arm:midway:multi_v7_defconfig:ecx-2000
	arm:realview-pb-a8:realview_defconfig
	arm:akita:spitz_defconfig
	arm:spitz:spitz_defconfig
	arm:akita:pxa_defconfig
	arm:borzoi:pxa_defconfig
	arm:mainstone:pxa_defconfig
	arm:spitz:pxa_defconfig
	arm:terrier:pxa_defconfig
	arm:tosa:pxa_defconfig
	arm:z2:pxa_defconfig
	arm:collie:collie_defconfig
	arm:integratorcp:integrator_defconfig:integratorcp
	mips:malta_defconfig:nosmp
	mips64:malta_defconfig:nosmp
	mipsel64:fuloong2e_defconfig:fulong2e
	powerpc:mac99:nosmp:ppc_book3s_defconfig
	powerpc:g3beige:nosmp:ppc_book3s_defconfig
	powerpc:virtex-ml507:44x/virtex5_defconfig
	powerpc:mpc8548cds:85xx/mpc85xx_cds_defconfig
	powerpc:bamboo:44x/bamboo_defconfig
	powerpc:nosmp:ppc64_book3s_defconfig
	sh:rts7751r2dplus_defconfig
	x86:core2duo:q35:x86_pc_nosmp_defconfig
	x86:Conroe:isapc:x86_pc_nosmp_defconfig
	x86:Opteron_G1:pc:x86_pc_nosmp_defconfig
	x86:n270:isapc:x86_pc_nosmp_defconfig
	x86_64:SandyBridge:q35:x86_64_pc_defconfig
	x86_64:Haswell:q35:x86_64_pc_defconfig
	x86_64:core2duo:pc:x86_64_pc_defconfig
	x86_64:Nehalem:q35:x86_64_pc_defconfig
	x86_64:phenom:pc:x86_64_pc_defconfig
	x86_64:Opteron_G1:q35:x86_64_pc_defconfig
	x86_64:Opteron_G4:pc:x86_64_pc_nosmp_defconfig
	x86_64:IvyBridge:q35:x86_64_pc_nosmp_defconfig
	xtensa:dc233c:ml605:generic_kc705_defconfig
	xtensa:dc233c:kc705:generic_kc705_defconfig

For logs, please see the next column of the qemu test results at
http://kerneltests.org/builders. You might have to dive into individual builds
if you check after a more recent -next kernel has been made available and your
changes were dropped in that kernel. Test results are available for about
a month.

Build and test scripts are available at https://github.com/groeck/linux-build-test.

Hope this helps,

Guenter

Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Mel Gorman]

On Fri, Jun 24, 2016 at 06:40:03AM -0700, Guenter Roeck wrote:
> Hi Mel,
> 
> On 06/24/2016 01:39 AM, Mel Gorman wrote:
> >On Thu, Jun 23, 2016 at 11:05:33PM -0700, Guenter Roeck wrote:
> >>Hi,
> >>
> >>I see a lot of crashes with various architectures in next-20160623.
> >>I bisected mips and sh; both bisect log point to the same patch.
> >>Bisect log is attached. arm, ppc, and x86 images crash as well,
> >>but I did not confirm if the same patch is the culprit there.
> >>
> >
> >The series has been dropped. Due to conflicts with other patches, there
> >were a few bugs introduced, one which potentially corrupted memory. Just
> >to be sure though, what sort of workload crashed just in case I need to
> >adjust the test coverage?
> >
> 
> This is just a basic qemu boot test. No workload at all.

Ok, is there any chance you could test the mm-vmscan-node-lru-v8r12
branch from git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
please?

If not, I'll work on replicating it some time next week before the
series is reposted.

-- 
Mel Gorman
SUSE Labs

Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Guenter Roeck]

On Fri, Jun 24, 2016 at 04:50:22PM +0100, Mel Gorman wrote:
> On Fri, Jun 24, 2016 at 06:40:03AM -0700, Guenter Roeck wrote:
> > Hi Mel,
> > 
> > On 06/24/2016 01:39 AM, Mel Gorman wrote:
> > >On Thu, Jun 23, 2016 at 11:05:33PM -0700, Guenter Roeck wrote:
> > >>Hi,
> > >>
> > >>I see a lot of crashes with various architectures in next-20160623.
> > >>I bisected mips and sh; both bisect log point to the same patch.
> > >>Bisect log is attached. arm, ppc, and x86 images crash as well,
> > >>but I did not confirm if the same patch is the culprit there.
> > >>
> > >
> > >The series has been dropped. Due to conflicts with other patches, there
> > >were a few bugs introduced, one which potentially corrupted memory. Just
> > >to be sure though, what sort of workload crashed just in case I need to
> > >adjust the test coverage?
> > >
> > 
> > This is just a basic qemu boot test. No workload at all.
> 
> Ok, is there any chance you could test the mm-vmscan-node-lru-v8r12
> branch from git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
> please?
> 
See the "testing" column at http://kerneltests.org/builders. "git describe"
is "v4.7-rc4-295-g572d768". Should be complete in a couple of hours.

Guenter

Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Mel Gorman]

On Fri, Jun 24, 2016 at 09:46:18AM -0700, Guenter Roeck wrote:
> > Ok, is there any chance you could test the mm-vmscan-node-lru-v8r12
> > branch from git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
> > please?
> > 
> See the "testing" column at http://kerneltests.org/builders. "git describe"
> is "v4.7-rc4-295-g572d768". Should be complete in a couple of hours.
> 

That appears to be mostly passing unless I'm reading it wrong.  There are a
number of build failures but from patches pending in linux-next and mmotm
instead of from the patch series itself.

Thanks very much.

-- 
Mel Gorman
SUSE Labs

Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy'

[Guenter Roeck]

On Fri, Jun 24, 2016 at 07:13:25PM +0100, Mel Gorman wrote:
> On Fri, Jun 24, 2016 at 09:46:18AM -0700, Guenter Roeck wrote:
> > > Ok, is there any chance you could test the mm-vmscan-node-lru-v8r12
> > > branch from git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
> > > please?
> > > 
> > See the "testing" column at http://kerneltests.org/builders. "git describe"
> > is "v4.7-rc4-295-g572d768". Should be complete in a couple of hours.
> > 
> 
> That appears to be mostly passing unless I'm reading it wrong.  There are a
> number of build failures but from patches pending in linux-next and mmotm
> instead of from the patch series itself.
> 

For the most part, yes. arm64 crashes, though, but I have no idea if
that is because of your series or because of some inherited problem.

Can you have a look ?

Guenter