--nextPart4890807.9PeoSSl85l Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Milian Wolff To: kwrite-devel@kde.org, Thiago Macieira Date: Mon, 20 Jun 2022 09:51:55 +0200 Message-ID: <1753234.ti610ilg2R@milian-workstation> In-Reply-To: <2119556.Icojqenx9y@tjmaciei-mobl5> MIME-Version: 1.0 On Sonntag, 19. Juni 2022 22:14:51 CEST Thiago Macieira wrote: > On Sunday, 19 June 2022 12:37:21 PDT Milian Wolff wrote: > > OK, this is apparently totally unrelated to git and kate. Thiago, do you > > happen to have an insight here maybe? Is it known that using QProcess can > > really badly influence the runtime behavior of malloc in other threads? > > It could... but it shouldn't be that meaningful. While the child process is > between fork() and execve(), it is sharing pages with the parent process but > they are COW. So attempting to allocate memory in the parent process > *could* cause that very COW to happen. > > If you waitForStarted() and the problem disappears, then this is why. But I > doubt it will be. > > > Here's a small example to trigger this behavior already: > > > > https://invent.kde.org/-/snippets/2239 > > > I have nproc == 24. Let's run this without any external processes: > > The example does waitForFinished, so the child process is surely past the > execve() stage. > > The threading code won't linearly scale. It is entirely thread-safe, but > you'll see contentions. The entire parent process' virtual address space is > shared with all children (one per thread) and given that many threads, the > chances are going to be very high that one thread will malloc() while at > least one child is still between fork() and execve(), thus causing COW. > > That said, this problem wouldn't be exclusive to memory allocations. The > simple fact of *running* threads will cause COW on those threads' stacks, > plus whatever other structures they touch. Ah, thank you Thiago, that explains it very well. I wonder, is there a reason why QProcess is not leveraging posix_spawn? That should help with this exact problem if I'm not mistaken, see e.g. [1]. But then again, this is certainly not an area where I'm proficient in. What's your take? [1]: https://github.com/rtomayko/posix-spawn#benchmarks Is there maybe a fundamental API limitation that makes that not a viable option for usage in QProcess? I could not find any prior discussion on this topic yet on the internet. forkfd has the spawnfd function, but it doesn't seem to be used by QProcess? Looking at its implementation, it even has this: ``` assert(!system_has_forkfd()); ``` Why is that? I would really like to learn a bit more on this. For starters, I expanded my trivial little snippet to get a similar subprocess behavior with posix_spawn (obviously lacking error reporting and such), which shows _very_ promising behavior on my machine: https://invent.kde.org/-/snippets/2241 ``` perf stat ./slow-malloc --with-subprocess --with-spawn Performance counter stats for './slow-malloc --with-subprocess --with-spawn': 7,291.83 msec task-clock:u # 11.476 CPUs utilized 0 context-switches:u # 0.000 /sec 0 cpu-migrations:u # 0.000 /sec 680,279 page-faults:u # 93.293 K/sec 11,531,120,738 cycles:u # 1.581 GHz (87.93%) 757,377,213 stalled-cycles-frontend:u # 6.57% frontend cycles idle (87.40%) 2,149,619,994 stalled-cycles-backend:u # 18.64% backend cycles idle (83.65%) 10,421,791,694 instructions:u # 0.90 insn per cycle # 0.21 stalled cycles per insn (85.42%) 2,329,873,392 branches:u # 319.518 M/sec (85.77%) 14,154,144 branch-misses:u # 0.61% of all branches (86.83%) 0.635415286 seconds time elapsed 2.661544000 seconds user 2.413737000 seconds sys ``` This is close to the original performance, and roughly 10x faster than using QProcess. Thanks -- Milian Wolff mail@milianw.de http://milianw.de --nextPart4890807.9PeoSSl85l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAmKwJxsACgkQ8zYW/HGd OX8GJRAAs3Q7A9RRIt9B7WGHda7q/pfdjURSjUG/Fqfx9mnaI9s8bfGn/VH6EL+K EQgoSVcpfSW7TbR6exD3V28B8RI5qsRCYZf2BsRMZXI0ys5ZF9XFqSTFOW5OnZFr iQJzn3cfdwiFsOIOlDFDm/8J7Tyq8gLmuRYZNg/sifu5Sf5aW8djV1nSmOFK1VBU ULBWNMvZwEBIl3COjMzQKW96s2/ISvnnKF0OhYFnSC2ZF1tC8iCCXPXMg3jQ+q7C 4YuA4eD/YtQMJAnmNlXj5HadLN4rQVusWpVQgqfRNBBvMS7Qclw3GUC13MjkgfDd lpl5lHo1qUtUYa8cZBEtbu35jU8FT2NdhgoRyn540l4VczhHAAypx8SxSIlc/uwT BGVvYAIfb12ZaTbUh4y/vnxsBsdrig5B3SR+/nJmPid+lkL8hcBhlKL+KvIxQjCz aFsXaodmqod2GA8DngMp+yxJKQUpp6EDDY0/yqRyFNcxbKQ7+zX4guUflSIIaNv/ Ac42lLZJe8il/6epwVNPx+lLw9N/S6npeodh98mk5HL7FgrGk2GZ7S0CZAp3yWcj CxufJ4Yq8aB+MVwqTMVLwKfcHYi5RyblkZIJK1sD2GCqJcvHKfnR9k1nOqhOOtry X2fu6i7JoAL4xhCGxrWBMqvnnD0pqBmuht2ROSRIXGY/njUgXD4= =4ils -----END PGP SIGNATURE----- --nextPart4890807.9PeoSSl85l--