On Tue, Oct 13, 2026 at 12:53:08PM -0700, Daniel Latypov wrote: > Firstly, thanks for taking on test parallelization! > In March 2022, I'd written a proof of concept that worked, it just > leaked some memory on the C side so I never shared it. > (Instead of using the existing test filter glob, I'd added the ability > to specify arbitrary test indices to run a slice of tests)
Perhaps that could be done by adding --run_isolated=N or A..B to split into numbered blocks of tests? TBH mine is implemented this way so we have to solve fewer problems but it does also feel sensible to be able to compose the paralleism and how things are split up. > I'd have to reacquaint myself with the code to actually review the series. > But one thing that sticks out immediately is, my version had added > this new type to avoid the need for any locking: > It required passing along kunit_printer.Printer objects to more > functions, but I think it might be a cleaner end result. > By explicitly calling `close()`, we could control when exactly output > gets flushed so we can avoid weird interleaving. > It seems in a later patch, you write each kernel's output to a file to > get the same effect, but an object like this could be used in more > places. The existing code does log the kernel output to test.log, this was piggybacking on that since those logs are there anyway - we'd want the separate logs regardless I think. That doesn't preclude doing in memory buffering though, from a first pass other than invasiveness the only big issue I can think of with buffering in memory is that if we faceplant badly enough it might be harder to figure out what went wrong but I'm not sure that's a real issue.
signature.asc
Description: PGP signature
