Excerpts from Tejun Heo's message of 2011-03-21 14:11:24 -0400: > Hello, > > On Mon, Mar 21, 2011 at 01:24:37PM -0400, Chris Mason wrote: > > Very interesting. Ok, I'll definitely rerun my benchmarks as well. I > > used dbench extensively during the initial tuning, but you're forcing > > the memory low in order to force IO. > > > > This case doesn't really hammer on the locks, it hammers on the > > transition from spinning to blocking. We want also want to compare > > dbench entirely in ram, which will hammer on the spinning portion. > > Here's re-run of DFL and SIMPLE with the memory restriction lifted. > Memory is 4GiB and disk remains mostly idle with all CPUs running > full. > > USER SYSTEM SIRQ CXTSW THROUGHPUT > DFL 59898 504517 377 6814245 782.295 > SIMPLE 61090 493441 457 1631688 827.751 > > So, about the same picture. Ok, this impact of this is really interesting. If we have very short waits where there is no IO at all, this patch tends to lose. I ran with dbench 10 and got about 20% slower tput. But, if we do any IO at all it wins by at least that much or more. I think we should take this patch and just work on getting rid of the scheduling with the mutex held where possible. Tejun, could you please send the mutex_tryspin stuff in? If we can get a sob for that I can send the whole thing. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
