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

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Fri, May 24, 2019 at 10:17:54AM +0200, Kamil Rytarowski wrote:

> Shouldn't that be optimized with libc functions? It calls read(2) for
> each character.

The input might be read by shell and programs launched by the shell.
For files you can read-ahead and seek back, but for pipes you can
only read single bytes.



> >> 2. Firefox and Thunderbird and certainly other similar software calls
> >> excessively gettimeofday() and clock_gettime(). At least around 100k
> >> times per 1 minute, and the program spends around 30sec (cumulative time
> >>from all LWPs in a process) in the kernel space prompting for the
> >> current time.
> > 
> > That's only a symptom. The real question is why it doesn't sleep.
> 
> This is a symptom, but this is not specific to a single application. In
> my checks other programs like top(1) are relatively hungry for checking
> for the current time. More than 70% syscalls from top(1) are for
> __gettimeofday50() (but of course top(1) doesn't emit so many syscalls
> in so short periods).

Top caches data from several databases (e.g. passwd) and checks time for
each lookup to find out whether the cache needs a refresh. Compared to
everything else done by top it is neglible.



> In NetBSD truss(1) we prompt for the current time for each event like a
> syscall entry/exit of a traced process.
> 
> Jason Thorpe mentioned how to optimize it. As far as I understand, we
> can create a page shared between userland and kernel, pass it through
> AUXV vector and effectively replace all syscalls with memory reads.

Yes, that is an option, als for other calls like getuid() or getpid().

On the other hand, your measurement is probably a bit misleading,
a modern system does 100k gettimeofday calls in about a millisecond.

I'm not sure whether the additional complexity would be justified.
Another argument against this optimization is that tracing these
non-syscalls is even more complex.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."