On Mon, 2013-06-10 at 17:51 -0700, Linus Torvalds wrote: > On Mon, Jun 10, 2013 at 5:44 PM, Steven Rostedt <rost...@goodmis.org> wrote: > > > > OK, I haven't found a issue here yet, but youss are beiing trickssy! We > > don't like trickssy, and we must find precccciouss!!! > > .. and I personally have my usual reservations. I absolutely hate > papering over scalability issues, and historically whenever people > have ever thought that we want complex spinlocks, the problem has > always been that the locking sucks. > > So reinforced by previous events, I really feel that code that needs > this kind of spinlock is broken and needs to be fixed, rather than > actually introduce tricky spinlocks. > > So in order to merge something like this, I want (a) numbers for real > loads and (b) explanations for why the spinlock users cannot be fixed.
I hate to be the bearer of bad news but I got some pretty bad aim7 performance numbers with this patch on an 8-socket (80 core) 256 Gb memory DL980 box against a vanilla 3.10-rc4 kernel: * shared workload: 10-100 users is in the noise area. 100-2000 users: -13% throughput. * high_systime workload: 10-700 users is in the noise area. 700-2000 users: -55% throughput. * disk: 10-100 users -57% throughput. 100-1000 users: -25% throughput 1000-2000 users: +8% throughput (this patch only benefits when we have a lot of concurrency). * custom: 10-100 users: -33% throughput. 100-2000 users: -46% throughput. * alltests: 10-1000 users is in the noise area. 1000-2000 users: -10% throughput. One notable exception is the short workload where we actually see positive numbers: 10-100 users: +40% throughput. 100-2000 users: +69% throughput. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
