tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD truss(1), coredumper(1) and performance bottlenecks



On 25.05.2019 14:41, Robert Elz wrote:
> 
>   | In my test I only
>   | used it against plain 'build.sh' without any arguments, so actually
>   | doing nothing interesting except printing usage text.
> 
> That's interesting.  Used like that, build.sh doesn't do almost anything
> at all, and in particular, doesn't do any read commands (it doesn't even
> reach the part that was discussed the other day).
> 
> I suspect that what you were measuring, more than anything, was your
> $ENV script - does that have "read" commands in it?
> 

Unlikely, but long term I plan to run a more appropriate tool. As a
proof of ptrace(2) stability I will try to run picotrace/truss for the
building process and this is what I have in my close term scope.

>   | I've picked build.sh as this is the only (?) script that is heavy in the
>   | native basesystem and could be useful to be optimized.
> 
> Again, I doubt that anyone would gain almost anything by optimising that
> script.   Optimising what happens when you "cd /usr/src; make ..."
> (with all the right options to make, and the environment set correctly)
> would make lots of sense.
> 

By 'build.sh' I mean './build.sh release' and all of the spawned
processes, so including make(1). Optimization is for all of its children
included.

truss(1) supports -f so it tracks all of its forks(/vforks/etc), they
cover make(1) commands that are called.

I'm not thinking about optimizing one single shell script as that would
make no sense.

>   | Personally I wouldn't bother with this. A simple profiler for such calls
>   | if we really need tham can be done with LD_PRELOAD and overwriting
>   | certain libc calls. Certainly there are other options with
>   | instrumentation (dynamorio? valgrind?).
> 
> I have no idea what you are thinking of there,

I was referring to the whole idea that with VDSO we have problems to
track libc calls (raised by Michael) and we shall do something with it.

I will try to write an libc symbol tracer as an exercise and proof that
it's nothing so impossible.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index