* Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> wrote: > Ingo, > > I ran the vanilla kernel, the kernel with all rwsem patches and the > kernel with all patches except the optimistic spin one. I am listing > two presentations of the data. Please note that there is about 5% > run-run variation. > > % change in performance vs vanilla kernel > #threads all without optspin > mmap only > 1 1.9% 1.6% > 5 43.8% 2.6% > 10 22.7% -3.0% > 20 -12.0% -4.5% > 40 -26.9% -2.0% > mmap with mutex acquisition > 1 -2.1% -3.0% > 5 -1.9% 1.0% > 10 4.2% 12.5% > 20 -4.1% 0.6% > 40 -2.8% -1.9% Silly question: how do the two methods of starting N threads compare to each other? Do they have identical runtimes? I think PeterZ's point was that the pthread_mutex case, despite adding extra serialization, actually runs faster in some circumstances. Also, mind posting the testcase? What 'work' do the threads do - clear some memory area? How big is the memory area? I'd expect this to be about large enough mmap()s showing page fault processing to be mmap_sem bound and the serialization via pthread_mutex() sets up a 'train' of threads in one case, while the parallel startup would run into the mmap_sem in the regular case. So I'd expect this to be a rather sensitive workload and you'd have to actively engineer it to hit the effect PeterZ mentioned. I could imagine MPI workloads to run into such patterns - but not deterministically. Only once you've convinced yourself that you are hitting that kind of effect reliably on the vanilla kernel, could/should the effects of an improved rwsem implementation be measured. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>