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]
Date:	Sun, 31 Jul 2011 11:11:07 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Pekka Enberg <penberg@...nel.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, hughd@...gle.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [GIT PULL] Lockless SLUB slowpaths for v3.1-rc1

On Sat, 30 Jul 2011, Linus Torvalds wrote:

> Oh, and another thing worth checking: did somebody actually check the
> timings for:
> 
>  - *just* the alignment change?
> 
>    IOW, maybe some of the netperf improvement isn't from the lockless
> path, but exactly from 'struct page' always being in a single
> cacheline?
> 

Without the lockless slowpath and only the struct page alignment, the 
performance improved only 0.18% compared to vanilla 3.0-rc5, which 
slub/lockless is based on.  I've only benchmarked this in Pekka's slab 
tree, I haven't looked at your tree since it was merged.

>  - check performance with cmpxchg16b *without* the alignment.
> 
>    Sometimes especially intel is so good at unaligned accesses that
> you wouldn't see an issue. Now, locked ops are usually special (and
> crossing cachelines with a locked op is dubious at best), so there may
> actually be correctness issues involved too, but it would be
> interesting to hear if anybody actually just tried it.
> 

If the alignment is removed and struct page is restructured back to what 
it was plus the additions required for the lockless slowpath with 
cmpxchg16b then it becomes not so happy on my testing cluster:

[    0.000000] general protection fault: 0000 [#1] SMP 
[    0.000000] CPU 0 
[    0.000000] Modules linked in:
[    0.000000] 
[    0.000000] Pid: 0, comm: swapper Not tainted 3.0.0-slub_noalign #1
[    0.000000] RIP: 0010:[<ffffffff81198f84>]  [<ffffffff81198f84>] get_partial_node+0xa4/0x1a0
[    0.000000] RSP: 0000:ffffffff81801d78  EFLAGS: 00010002
[    0.000000] RAX: ffff88047f801040 RBX: 0000000000000000 RCX: 0000000180400040
[    0.000000] RDX: 0000000100400001 RSI: ffff88047f801040 RDI: ffffea000fbe4048
[    0.000000] RBP: ffffffff81801de8 R08: ffff88047fc132c0 R09: ffffffff8119e69c
[    0.000000] R10: 0000000000001800 R11: 0000000000001000 R12: ffffea000fbe4038
[    0.000000] R13: ffff88047f800100 R14: ffff88047f801000 R15: ffff88047f801010
[    0.000000] FS:  0000000000000000(0000) GS:ffff88047fc00000(0000) knlGS:0000000000000000
[    0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.000000] CR2: 0000000000000000 CR3: 0000000001803000 CR4: 00000000000006b0
[    0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    0.000000] Process swapper (pid: 0, threadinfo ffffffff81800000, task ffffffff8180b020)
[    0.000000] Stack:
[    0.000000]  ffff88107ffd8e00 0000000000000000 ffff88047ffda1d8 0000000180400040
[    0.000000]  ffff00066c0a0100 ffffffff8108a1f9 ffffffff81801dc8 ffffffff815a543c
[    0.000000]  0000000000000000 ffffffff8180b020 0000000000000000 ffff88047f800100
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff8108a1f9>] ? __might_sleep+0x9/0xf0
[    0.000000]  [<ffffffff815a543c>] ? mutex_lock+0x2c/0x60
[    0.000000]  [<ffffffff8119df35>] kmem_cache_alloc_node+0x135/0x560
[    0.000000]  [<ffffffff8119e69c>] ? kmem_cache_open+0x33c/0x580
[    0.000000]  [<ffffffff81199cf6>] ? calculate_sizes+0x16/0x3f0
[    0.000000]  [<ffffffff8119e69c>] kmem_cache_open+0x33c/0x580
[    0.000000]  [<ffffffff81194df6>] ? alloc_pages_current+0x96/0x130
[    0.000000]  [<ffffffff818c6c25>] kmem_cache_init+0xbb/0x462
[    0.000000]  [<ffffffff818a3ce7>] start_kernel+0x1be/0x39e
[    0.000000]  [<ffffffff818a3520>] x86_64_start_kernel+0x203/0x20a
[    0.000000] Code: 10 48 89 55 a8 41 0f b7 44 24 1a 80 4d ab 80 66 25 ff 7f 66 89 45 a8 48 8b 4d a8 9c 58 41 f6 45 0b 40 0f 84 7f 00 00 00 48 89 f0 <f0> 48 0f c7 0f 0f 94 c0 84 c0 0f 84 86 00 00 00 49 8b 54 24 20 
[    0.000000] RIP  [<ffffffff81198f84>] get_partial_node+0xa4/0x1a0
[    0.000000]  RSP <ffffffff81801d78>
[    0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---
[    0.000000] Kernel panic - not syncing: Fatal exception
[    0.000000] Pid: 0, comm: swapper Not tainted 3.0.0-slub_noalign #1
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff815a33fb>] panic+0x91/0x198
[    0.000000]  [<ffffffff81052b87>] die+0x247/0x260
[    0.000000]  [<ffffffff815a7952>] do_general_protection+0x162/0x170
[    0.000000]  [<ffffffff815a716f>] general_protection+0x1f/0x30
[    0.000000]  [<ffffffff8119e69c>] ? kmem_cache_open+0x33c/0x580
[    0.000000]  [<ffffffff81198f84>] ? get_partial_node+0xa4/0x1a0
[    0.000000]  [<ffffffff8108a1f9>] ? __might_sleep+0x9/0xf0
[    0.000000]  [<ffffffff815a543c>] ? mutex_lock+0x2c/0x60
[    0.000000]  [<ffffffff8119df35>] kmem_cache_alloc_node+0x135/0x560
[    0.000000]  [<ffffffff8119e69c>] ? kmem_cache_open+0x33c/0x580
[    0.000000]  [<ffffffff81199cf6>] ? calculate_sizes+0x16/0x3f0
[    0.000000]  [<ffffffff8119e69c>] kmem_cache_open+0x33c/0x580
[    0.000000]  [<ffffffff81194df6>] ? alloc_pages_current+0x96/0x130
[    0.000000]  [<ffffffff818c6c25>] kmem_cache_init+0xbb/0x462
[    0.000000]  [<ffffffff818a3ce7>] start_kernel+0x1be/0x39e
[    0.000000]  [<ffffffff818a3520>] x86_64_start_kernel+0x203/0x20a
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ