On Sun Aug 12 19:11:59 GMT 2018, cinap_lenrek@felloff.net wrote:
> this sucks. burnzez talked to me explaining the lack of
> resolution of kernel process time accounting but no context
> has been given in this patch.

This patch is unrelated to the accounting resolution issues.
Process-level accounting will never consider the time it takes to
exec(), which ends up being important when the latency itself can
unexpectedly (even sporadically) be an order of magnitude higher than
the accounted execution time of the program.


> as for the patch... no. i dont like it. its a kludgy work
> arround, not addressing the problem. and i dont see why you
> need segattach() at all.

Yeah, segattach isn’t necessary, but seemed the most straightforward
thing.  The child process also makes use of that ‘output’ array.
	sprint(output, "/bin/%s", argv[1]);

If RFMEM is used when rfork is called, then would it make sense to:
	∙ define another array
	∙ use smprint() instead of sprint
	∙ set output[0] to NUL and proceed

The last one makes the most sense to me, but that doesn’t mean it’s
not retarded for some reason.

Attached diff shows how I would do it without segattach(), but I’m
not confident it’s correct.
(also removed the 2nd t0 assignment, as I realized that a latency
spike during the first exec() would be overlooked)