* Davidlohr Bueso <davidlohr@xxxxxx> wrote: > > 2) > > > > I don't see the justification: this code gets executed in exec() where > > a new mm has just been allocated. There's only a single user of the mm > > and thus the critical section width of mmap_sem is more or less > > irrelevant. > > > > mmap_sem critical section size only matters for codepaths that > > threaded programs can hit. > > Yes, I was surprised by the performance boost I noticed when running > this patch. This weekend I re-ran the tests (including your 4/3 patch) > and noticed that while we're still getting some benefits (more like in > the +5% throughput range), it's not as good as I originally reported. I > believe the reason is because I had ran the tests on the vanilla kernel > without the max clock frequency, so the comparison was obviously not > fair. That said, I still think it's worth adding this patch, as it does > help at a micro-optimization level, and it's one less mmap_sem user we > have to worry about. But it's a mmap_sem user that is essentially _guaranteed_ to have only a single user at that point, in the exec() path! So I don't see how this can show _any_ measurable speedup, let alone a 5% speedup in a macro test. If our understanding is correct then the patch does nothing but shuffle around a flag setting operation. (the mmap_sem is equivalent to setting a single flag, in the single-user case.) Now, if our understanding is incorrect then we need to improve our understanding. 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>