On Mon, Jan 20, 2025 at 9:31 PM Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > I'm afraid my emails can look as if I am trying to deny the problem. > No. Just I think we need to understand why exactly this patch makes > a difference. > I agree. I was going to state there is 0 urgency as long as the patch does not make the merge window, but it just did. Since the change does not introduce a bug or crater performance (that we know of anyway), I guess this outcome still means there is 0 urgency. ;) > And I don't understand what workload this logic tries to simulate, but > this doesn't matter. > So one would preferably survey a bunch of real workloads, see what happens with real pipes with both policies -- the early wake up is basically a tradeoff and it very well may be it is worth it in the real world. However, I would argue cycles needed to for such an effort would be best spent on other things. Per one of my previous messages the tee thing which got a significant win is doing some crap which should be avoided in real programs. The rest, with unknown real-world applicability, does suffer losses. The early wake up definitely has its own merits, so one can't say outright it was the right call to whack it. My suggestion to Christian is to revert the patch and call it a day. For all I know there are other yet to be reported regressions lurking (wins as well of course :>). By now there is no denying there is more to the patch than originally anticipated, but it is also doubtful it is worth poking around. If you feel nerd sniped to figure this out, then well, more power to you. :) Perhaps someone(tm) would be interested in looking at pipe performance in general. I can tell you right now that there is definitely loss stemming from repeated SMAP trips when changing buffers etc. Trying to get a real understanding what's up with pipes vs real workloads and fixing whatever crappers which pop up would justify the investigation. That said I'm buggering off this issue, cheers :) -- Mateusz Guzik <mjguzik gmail.com>
