Re: tar x cpu bound

[Christoph Badura <bad%bsd.de@localhost>]

On Mon, May 12, 2025 at 06:45:06PM +0200, Edgar Fuß wrote:
> As suggested privately by riastradh@, I ran the tar command under dtrace
> 	dtrace -n 'profile:::profile-97 { @[stack()] = count() }' -c ...
> and got output I can't make sense of. I attach the last (top-count) lines.
> 
> The first thing I don't understand is why the top (or the two top) hits 
> are in idle_loop. Is that because the other fives cores are idle?

Looks to me like they are likely from interrupts.  Maybe timer interrupts?

You said nothing about the system you are running this on.  How many cores?
What kind of disks?  Are they using MSI/MSIX to distribute interrupts to
multiple CPUs?  What file system and what mount options?

Perhaps you should run your tests to extract to a tmpfs, to remove vagaries
from hardware from the experiment and to establish a baseline.

> The second question is what the single number without a backtrace means.

That is the number of time that the backtrace was sampled.

Maybe you want to generate some flame graphs from the sampled data.
Brendan Gregg has written a lot about them
- https://www.brendangregg.com/flamegraphs.html
- https://github.com/brendangregg/FlameGraph
The latter is in pkgsrc.

> And the third question is that I would have expected a large amount of 
> hits in the write system call if the problem really was stdio to issue 
> small writes.

That's what we want to find out, isn't it?  Where it actually spends time
instead of what we're expecting/second guessing where it spends time.

--chris