* Davidlohr Bueso <davidl...@hp.com> 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 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/
