I do not hate this series, and I'd be happy to apply it, but I will
repeat what I've asked for EVERY SINGLE TIME this series has come up:
On Thu, Oct 12, 2017 at 4:03 PM, Mathieu Desnoyers
<mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>
> Here are benchmarks of counter increment in various scenarios compared
> to restartable sequences. Those benchmarks were taken on v8 of the
> patchset.
I want to see real numbers from real issues.
A "increment percpu value" simply isn't relevant.
When I asked last time, people pointed me to potential uses, including
malloc libraries that could get per-thread performance with just
per-cpu (not per thread) data structure overhead. I see that you once
more point to the slides from 2013 that again talks about it.
But people didn't post code, people didn't post numbers, and people
didn't point to actual real uses, just "this could happen".
I really really want more than hand-waving. I want more than pointless
"this is how quickly you can increment a per-thread counter". I want
to hear about _real_ uses, and real numbers.
This has been going on for long enough, that if there *still* are no
actual real users, then I'm *still* not interested in having this
merged.
Because without real-world uses, it's not obvious that there won't be
somebody who goes "oh, this isn't quite enough for us, the semantics
are subtly incompatible with our real-world use case".
So I want real numbers from a real implementation of malloc/free. And
if it's not malloc/free, then what is it? I want something *real*, not
some micro-benchmark that benchmarks a totally pointless load.
Because until there are that kind of "yes, this is more than theory",
I'm not really willing to have this merged.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
