Re: [brauner-vfs:vfs-6.14.misc] [pipe_read] aaec5a95d5: hackbench.throughput 7.5% regression

[Oleg Nesterov <oleg@redhat.com>]

Well, I guess I need to react somehow...

On 01/10, kernel test robot wrote:
>
> kernel test robot noticed a 7.5% regression of hackbench.throughput on:
>
> commit: aaec5a95d59615523db03dd53c2052f0a87beea7 ("pipe_read: don't wake up the writer if the pipe is still full")
> https://git.kernel.org/cgit/linux/kernel/git/vfs/vfs.git vfs-6.14.misc

Hmm. Not good ;)

But otoh,

> In addition to that, the commit also has significant impact on the following tests:
>
> +------------------+-------------------------------------------------------------------------------------------+
> | testcase: change | stress-ng: stress-ng.tee.ops_per_sec 500.7% improvement                                   |

So I hope we do not need to revert this patch?

-------------------------------------------------------------------------------
I am looking at

	https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/hackbench/hackbench.c

and I don't understand how can this patch make a noticable difference.
And can't reproduce,

	hackbench -g 4 -f 10 --process --pipe -l 50000 -s 100

on my laptop under qemu doesn't show any regression.

OK, in this case the early/unnecessary wakeup (removed by this patch) is
not necessarily bad, when the woken writer actually gets CPU pipe_full()
will be likely false, plus receiver() can wakeup more writers when it does
the next read()s. But 7.5% ?

Perhaps this is another case which shows that "artificial" benchmarks like
this one are very sensitive... Or perhaps I am trying to deny the problem.

So, Christian, et al, unless you think I should try to investigate, I am
going to forget this report. If nothing else, "500.7% improvement" doesn't
look bad even if I have no idea whether the stress-ng.tee.ops_per_sec test
realistic or not (I have no idea what does it do).

Oleg.