Re: 4.1 regression in resizable hashtable tests
On 07/02/15 at 10:09pm, Meelis Roos wrote: [ 33.425061] Running rhashtable test nelem=8, max_size=65536, shrinking=0 [ 33.425154] Test 00: [ 33.534470] Adding 5 keys [ 34.743553] Info: encountered resize [ 34.743698] Info: encountered resize [ 34.743838] Info: encountered resize [ 34.744057] Info: encountered resize [ 34.744430] Info: encountered resize [ 34.745139] Info: encountered resize [ 34.746441] Info: encountered resize [ 34.749055] Info: encountered resize [ 34.754469] Info: encountered resize [ 34.764836] Info: encountered resize [ 34.785696] Info: encountered resize [ 34.827448] Info: encountered resize [ 34.896936] Traversal complete: counted=49993, nelems=5, entries=5, table-jumps=12 [ 34.897056] Test failed: Total count mismatch ^^^ I do see count mismatches as well due to the design of the walker which restarts and thus sees certain entries multiple times. Do you have this commit as well? Author: Phil Sutter p...@nwl.cc Date: Mon Jul 6 15:51:20 2015 +0200 rhashtable: fix for resize events during table walk -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.1 regression in resizable hashtable tests
On 07/17/15 at 12:26pm, Phil Sutter wrote: On Fri, Jul 17, 2015 at 10:04:56AM +0200, Thomas Graf wrote: On 07/02/15 at 10:09pm, Meelis Roos wrote: [ 33.425061] Running rhashtable test nelem=8, max_size=65536, shrinking=0 [ 33.425154] Test 00: [ 33.534470] Adding 5 keys [ 34.743553] Info: encountered resize [ 34.743698] Info: encountered resize [ 34.743838] Info: encountered resize [ 34.744057] Info: encountered resize [ 34.744430] Info: encountered resize [ 34.745139] Info: encountered resize [ 34.746441] Info: encountered resize [ 34.749055] Info: encountered resize [ 34.754469] Info: encountered resize [ 34.764836] Info: encountered resize [ 34.785696] Info: encountered resize [ 34.827448] Info: encountered resize [ 34.896936] Traversal complete: counted=49993, nelems=5, entries=5, table-jumps=12 [ 34.897056] Test failed: Total count mismatch ^^^ I do see count mismatches as well due to the design of the walker which restarts and thus sees certain entries multiple times. Do you have this commit as well? Author: Phil Sutter p...@nwl.cc Date: Mon Jul 6 15:51:20 2015 +0200 rhashtable: fix for resize events during table walk Thomas, this should be resolved already. Meelis replied[1] to my patch, stating it fixes that problem for him. Though he's still waiting for your proposed patch to add a schedule() call so the kernel won't complain on his slow UltraSparc. :) Cheers, Phil [1]: http://www.spinics.net/lists/netdev/msg335767.html OK, good to know. I've posted the schedule patch today: https://patchwork.ozlabs.org/patch/497035/ -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.1 regression in resizable hashtable tests
On Fri, Jul 17, 2015 at 10:04:56AM +0200, Thomas Graf wrote: On 07/02/15 at 10:09pm, Meelis Roos wrote: [ 33.425061] Running rhashtable test nelem=8, max_size=65536, shrinking=0 [ 33.425154] Test 00: [ 33.534470] Adding 5 keys [ 34.743553] Info: encountered resize [ 34.743698] Info: encountered resize [ 34.743838] Info: encountered resize [ 34.744057] Info: encountered resize [ 34.744430] Info: encountered resize [ 34.745139] Info: encountered resize [ 34.746441] Info: encountered resize [ 34.749055] Info: encountered resize [ 34.754469] Info: encountered resize [ 34.764836] Info: encountered resize [ 34.785696] Info: encountered resize [ 34.827448] Info: encountered resize [ 34.896936] Traversal complete: counted=49993, nelems=5, entries=5, table-jumps=12 [ 34.897056] Test failed: Total count mismatch ^^^ I do see count mismatches as well due to the design of the walker which restarts and thus sees certain entries multiple times. Do you have this commit as well? Author: Phil Sutter p...@nwl.cc Date: Mon Jul 6 15:51:20 2015 +0200 rhashtable: fix for resize events during table walk Thomas, this should be resolved already. Meelis replied[1] to my patch, stating it fixes that problem for him. Though he's still waiting for your proposed patch to add a schedule() call so the kernel won't complain on his slow UltraSparc. :) Cheers, Phil [1]: http://www.spinics.net/lists/netdev/msg335767.html -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.1 regression in resizable hashtable tests
On Fri, Jul 17, 2015 at 12:26:36PM +0200, Phil Sutter wrote: On Fri, Jul 17, 2015 at 10:04:56AM +0200, Thomas Graf wrote: On 07/02/15 at 10:09pm, Meelis Roos wrote: [ 33.425061] Running rhashtable test nelem=8, max_size=65536, shrinking=0 [ 33.425154] Test 00: [ 33.534470] Adding 5 keys [ 34.743553] Info: encountered resize [ 34.743698] Info: encountered resize [ 34.743838] Info: encountered resize [ 34.744057] Info: encountered resize [ 34.744430] Info: encountered resize [ 34.745139] Info: encountered resize [ 34.746441] Info: encountered resize [ 34.749055] Info: encountered resize [ 34.754469] Info: encountered resize [ 34.764836] Info: encountered resize [ 34.785696] Info: encountered resize [ 34.827448] Info: encountered resize [ 34.896936] Traversal complete: counted=49993, nelems=5, entries=5, table-jumps=12 [ 34.897056] Test failed: Total count mismatch ^^^ I do see count mismatches as well due to the design of the walker which restarts and thus sees certain entries multiple times. Do you have this commit as well? Author: Phil Sutter p...@nwl.cc Date: Mon Jul 6 15:51:20 2015 +0200 rhashtable: fix for resize events during table walk Thomas, this should be resolved already. Meelis replied[1] to my patch, stating it fixes that problem for him. Though he's still waiting for your proposed patch to add a schedule() call so the kernel won't complain on his slow UltraSparc. :) Ah, nevermind. You sent it already with him in Cc. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.1 regression in resizable hashtable tests
On 07/01/15 at 01:21pm, Meelis Roos wrote: This is 4.1 on sparc64 - one of my boxes that happens to have most runtime test left on from some debugging effort. In 4.0 it was fine, 4.1 gives this in dmesg: [ 31.898697] Running resizable hashtable tests... [ 31.898915] Adding 2048 keys [ 31.952911] Traversal complete: counted=17, nelems=2048, entries=2048 [ 31.953004] Test failed: Total count mismatch ^^^ [ 32.022676] Traversal complete: counted=17, nelems=2048, entries=2048 [ 32.022788] Test failed: Total count mismatch ^^^ [ 32.022828] Deleting 2048 keys Thanks for the report. I think this is already fixed. Can you try with the following commit: commit 246b23a7695bd5a457aa51a36a948cce53d1d477 Author: Thomas Graf tg...@suug.ch Date: Thu Apr 30 22:37:44 2015 + rhashtable-test: Use walker to test bucket statistics As resizes may continue to run in the background, use walker to ensure we see all entries. Also print the encountered number of rehashes queued up while traversing. This may lead to warnings due to entries being seen multiple times. We consider them non-fatal. Signed-off-by: Thomas Graf tg...@suug.ch Signed-off-by: David S. Miller da...@davemloft.net -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.1 regression in resizable hashtable tests
[ 31.898697] Running resizable hashtable tests... [ 31.898915] Adding 2048 keys [ 31.952911] Traversal complete: counted=17, nelems=2048, entries=2048 [ 31.953004] Test failed: Total count mismatch ^^^ [ 32.022676] Traversal complete: counted=17, nelems=2048, entries=2048 [ 32.022788] Test failed: Total count mismatch ^^^ [ 32.022828] Deleting 2048 keys Thanks for the report. I think this is already fixed. Can you try with the following commit: commit 246b23a7695bd5a457aa51a36a948cce53d1d477 Tried todays got, it's actually worse: [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36' [0.00] PROMLIB: Root node compatible: [0.00] Linux version 4.1.0-12127-g4da3064 (mroos@u5) (gcc version 4.9.2 (Debian 4.9.2-20) ) #19 Thu Jul 2 21:09:48 EEST 2015 [0.00] bootconsole [earlyprom0] enabled [0.00] ARCH: SUN4U [0.00] Ethernet address: 08:00:20:f8:c7:72 [0.00] MM: PAGE_OFFSET is 0xf800 (max_phys_bits == 40) [0.00] MM: VMALLOC [0x0001 -- 0x0600] [0.00] MM: VMEMMAP [0x0600 -- 0x0c00] [0.00] Kernel: Using 10 locked TLB entries for main kernel image. [0.00] Remapping the kernel... done. [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,40:a [0.00] PROM: Built device tree with 70266 bytes of memory. [0.00] Top of RAM: 0x1ff2c000, Total RAM: 0x1ff2a000 [0.00] Memory hole size: 0MB [0.00] Allocated 16384 bytes for kernel page tables. [0.00] Zone ranges: [0.00] Normal [mem 0x-0x1ff2bfff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x1fefdfff] [0.00] node 0: [mem 0x1ff0-0x1ff2bfff] [0.00] Initmem setup node 0 [mem 0x-0x1ff2bfff] [0.00] On node 0 totalpages: 65429 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 65429 pages, LIFO batch:15 [0.00] Booting Linux... [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus] [0.00] CPU CAPS: [vis] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64917 [0.00] Kernel command line: root=/dev/sda1 ro [0.00] PID hash table entries: 2048 (order: 1, 16384 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 524288 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 262144 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 475912K/523432K available (5266K kernel code, 516K rwdata, 1672K rodata, 520K init, 30210K bss, 47520K reserved, 0K cma-reserved) [0.00] Running RCU self tests [0.00] Testing tracer nop: PASSED [0.00] NR_IRQS:2048 nr_irqs:2048 1 [ 26.997388] clocksource: tick: mask: 0x max_cycles: 0x5306eb473f, max_idle_ns: 440795213232 ns [ 27.101123] clocksource: mult[2c71c72] shift[24] [ 27.140662] clockevent: mult[5c28f5c3] shift[32] [ 27.182668] Console: colour dummy device 80x25 [ 27.218768] console [tty0] enabled [ 27.243489] bootconsole [earlyprom0] disabled [ 27.279960] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 27.280027] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 27.280070] ... MAX_LOCK_DEPTH: 48 [ 27.280114] ... MAX_LOCKDEP_KEYS:8191 [ 27.280159] ... CLASSHASH_SIZE: 4096 [ 27.280204] ... MAX_LOCKDEP_ENTRIES: 32768 [ 27.280250] ... MAX_LOCKDEP_CHAINS: 65536 [ 27.280295] ... CHAINHASH_SIZE: 32768 [ 27.280341] memory used by lock dependency info: 8159 kB [ 27.280392] per task-struct memory footprint: 1920 bytes [ 27.280443] [ 27.280480] | Locking API testsuite: [ 27.280518] [ 27.280584] | spin |wlock |rlock |mutex | wsem | rsem | [ 27.280650] -- [ 27.280755] A-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.347473] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.414742] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.482380] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | [ 27.550106] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.618220] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok |
