Re: [9front] time

[cinap_lenrek@felloff.net]

>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.

no. it is very much related, because the times returned by
wait() are supposed to provide the same information you want,
just lacking resolution at the moment.

> 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.

of course it does. theres nothing special about exec. the accounting
starts when the *process* is created, not after exec(). also, it is
hard to know what you consider time spend execing. the exec itself
just reads the programs a.out header and creates the segments.
the pages get faulted in during the runtime of the program *after*
exec did its job.

>> 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.

all of this doesnt matter. you'r adding your own nsec() calls because
the resolution of the wait times sucks. i think we should rather consider
improving the kernels process time accounting so that this code doesnt
need to exist.

--
cinap