Hi,
On 26/09/2017 01:34, Andrew Morton wrote:
On Mon, 25 Sep 2017 09:27:43 -0700 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:
On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour
<ldufour@xxxxxxxxxxxxxxxxxx> wrote:
Despite the unprovable lockdep warning raised by Sergey, I didn't get any
feedback on this series.
Is there a chance to get it moved upstream ?
what is the status ?
We're eagerly looking forward for this set to land,
since we have several use cases for tracing that
will build on top of this set as discussed at Plumbers.
There has been sadly little review and testing so far :(
I do agree and I could just encourage people to do so :/
I'll be taking a close look at it all over the next couple of weeks.
Thanks Andrew for giving it a close look.
One terribly important thing (especially for a patchset this large and
intrusive) is the rationale for merging it: the justification, usually
in the form of end-user benefit.
The benefit is only for multi-threaded processes. But even on *small*
systems with 16 CPUs, there is a real benefit.
Laurent's [0/n] provides some nice-looking performance benefits for
workloads which are chosen to show performance benefits(!) but, alas,
no quantitative testing results for workloads which we may suspect will
be harmed by the changes(?).
I did test with kernbench, involving gcc/ld which are not
multi-threaded, AFAIK, and I didn't see any impact.
But if you know additional test I should give a try, please advise.
Regarding ebizzy, it was designed to simulate web server's activity, so
I guess there will be improvements when running real web servers.
Even things as simple as impact upon
single-threaded pagefault-intensive workloads and its effect upon
CONFIG_SMP=n .text size?
If you have additional usecases then please, spell them out for us in
full detail so we can better understand the benefits which this
patchset provides.
The other use-case I'm aware of is on memory database, where performance
improvements is really significant, as I mentioned in the header of my
series.
Cheers,
Laurent.
--
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>
