mirror of https://gitee.com/openkylin/linux.git
d637413f3f
On our raw spinlocks, we currently have an attempt at the lock, and if we do not get it we enter a spin loop. This spinloop will likely continue for awhile, and we pridict likely. Shouldn't we predict that we will get out of the loop so our next instructions are already prefetched. Even when we miss because the lock is still held, it won't matter since we are waiting anyways. I did a couple quick benchmarks, but the results are inconclusive. 16-way 690 running specjbb with original code # ./specjbb 3000 16 1 1 19 30 120 ... Valid run, Score is 59282 16-way 690 running specjbb with unlikely code # ./specjbb 3000 16 1 1 19 30 120 ... Valid run, Score is 59541 I saw a smaller increase on a JS20 (~1.6%) JS20 specjbb w/ original code # ./specjbb 400 2 1 1 19 30 120 ... Valid run, Score is 20460 JS20 specjbb w/ unlikely code # ./specjbb 400 2 1 1 19 30 120 ... Valid run, Score is 20803 Anton said: Mispredicting the spinlock busy loop also means we slow down the rate at which we do the loads which can be good for heavily contended locks. Note: There are some gcc issues with our default build and branch prediction, but a CONFIG_POWER4_ONLY build should emit them correctly. I'm working with Alan Modra on it now. Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-alpha | ||
| asm-arm | ||
| asm-arm26 | ||
| asm-cris | ||
| asm-frv | ||
| asm-generic | ||
| asm-h8300 | ||
| asm-i386 | ||
| asm-ia64 | ||
| asm-m32r | ||
| asm-m68k | ||
| asm-m68knommu | ||
| asm-mips | ||
| asm-parisc | ||
| asm-ppc | ||
| asm-ppc64 | ||
| asm-s390 | ||
| asm-sh | ||
| asm-sh64 | ||
| asm-sparc | ||
| asm-sparc64 | ||
| asm-um | ||
| asm-v850 | ||
| asm-x86_64 | ||
| linux | ||
| math-emu | ||
| media | ||
| mtd | ||
| net | ||
| pcmcia | ||
| rxrpc | ||
| scsi | ||
| sound | ||
| video | ||