linux-kernel - Re: Huge memory takes too long time to initialize on 4TB ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1205232146450.10366@chino.kir.corp.google.com>
Date:	Wed, 23 May 2012 21:48:17 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	ethan zhao <ethan.kernel@...il.com>
cc:	Andrea Arcangeli <aarcange@...hat.com>,
	linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de>
Subject: Re: Huge memory takes too long time to initialize on 4TB ?

On Thu, 24 May 2012, ethan zhao wrote:

> BUG: soft lockup - CPU#60 stuck for 21s! [swapper:1]
> Modules linked in:
> CPU 60
> Modules linked in:
> 
> Pid: 1, comm: swapper Not tainted 2.6.39-100.6.1.el6uek.x86_64 #1
> Oracle Corporation  Sun Fire X4800 M2 /
> RIP: 0010:[<ffffffff814fb2d9>]  [<ffffffff814fb2d9>]
> _raw_spin_unlock_irqrestore+0x19/0x30
> RSP: 0000:ffff887d8efbfe38  EFLAGS: 00000286
> RAX: 0000000038080200 RBX: ffff887d8efbfe00 RCX: 0340000000000400
> RDX: ffffea0c41bfe8d0 RSI: 0000000000000286 RDI: 0000000000000286
> RBP: ffff887d8efbfe40 R08: 0000000000000004 R09: 0000000000000000
> R10: ffff8b807ffcbfe8 R11: 0000000000014f50 R12: ffffffff81503f4e
> R13: ffffea0a81c00000 R14: ffff897d8d69b060 R15: ffff897d8d69b000
> FS:  0000000000000000(0000) GS:ffff8b807f800000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001761000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo ffff887d8efbe000, task ffff887d8efbc040)
> Stack:
>  ffff8b807ffece00 ffff887d8efbfe80 ffffffff811105d1 ffff887d8efbfe80
>  ffffffff819aee60 0000000000000000 ffffffff814f7483 0000000000000000
>  0000000000000000 ffff887d8efbfea0 ffffffff814f74c0 ffffffff819aee58
> Call Trace:
>  [<ffffffff811105d1>] setup_per_zone_wmarks+0xb1/0xe0
>  [<ffffffff814f7483>] ? free_area_init_node+0xcb/0xcb
>  [<ffffffff814f74c0>] init_per_zone_wmark_min+0x3d/0x8b
>  [<ffffffff81002043>] do_one_initcall+0x43/0x190
>  [<ffffffff818c46fd>] kernel_init+0x15b/0x1e6
>  [<ffffffff815046a4>] kernel_thread_helper+0x4/0x10
>  [<ffffffff818c45a2>] ? parse_early_options+0x20/0x20
>  [<ffffffff815046a0>] ? gs_change+0x13/0x13

Yeah, this confirms what I was suspecting in that its a soft lockup 
because irqs aren't getting enabled for a lengthy period of time due to 
how long setup_per_zone_wmarks() takes for your system with 4TB of RAM.  
3.3 or later kernels should significantly improve this.  If there's still 
an issue, please let us know.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/