Re: top(1) behavior
On Thu, Aug 10, 2023 at 02:13:12PM -0700, Kevin Bowling wrote: > When running something heavy yet ephemeral like a parallel make, I can > see expected CPU usage in the summary or per-cpu view. However, I > rarely see the process(es) consuming the CPU momentarily during the > update intervals reflected accordingly in the per process view below. > I find the behavior somewhat surprising compared to FreeBSD top(1) and > am wondering what the difference is. You mean you often don't see the process with STATE CPU/0 (or some other cpu)? Maybe FreeBSD uses a different default sort - you could try experimenting if you get similar display with something like "top -o ..." and various sort fields. Martin
Re: top(1) behavior
On Fri, Aug 11, 2023 at 2:01 AM Martin Husemann wrote: > > On Thu, Aug 10, 2023 at 02:13:12PM -0700, Kevin Bowling wrote: > > When running something heavy yet ephemeral like a parallel make, I can > > see expected CPU usage in the summary or per-cpu view. However, I > > rarely see the process(es) consuming the CPU momentarily during the > > update intervals reflected accordingly in the per process view below. > > I find the behavior somewhat surprising compared to FreeBSD top(1) and > > am wondering what the difference is. > > You mean you often don't see the process with STATE CPU/0 (or some other > cpu)? Hi Martin, A real example is doing a -j 8 kernel build. Up in the top of top(1), I see global CPU usage in the high 90%. Down in the process list, I see a few processes in the 1-10% range that do not add up to 800%. I see some of the cc1 processes with 0% WCPU%/CPU%. > Maybe FreeBSD uses a different default sort - you could try experimenting > if you get similar display with something like "top -o ..." and various > sort fields. I checked these fields out, sorting by cpu for instance and see the same deal. I checked FreeBSD and Linux and they don't get it perfect.. the former seems to have slightly better accounting of momentary processes down in the process list somehow though. > Martin
Re: top(1) behavior
On Fri, Aug 11, 2023 at 07:04:01PM -0700, Kevin Bowling wrote: > A real example is doing a -j 8 kernel build. Up in the top of top(1), > I see global CPU usage in the high 90%. Down in the process list, I > see a few processes in the 1-10% range that do not add up to 800%. I > see some of the cc1 processes with 0% WCPU%/CPU%. I am not sure I see what you mean, for me typically there are a few gcc processes that take all the cpu, or later (close to the end) a few xz or gzip processes. At a few spots ld wins and hogs at least one cpu completely. At least it looks not completely off, the top area displays statistics for aggregated intervals, while many processes (besides the ones mentioned) are very short lived - so the display is mostly what I'd expect it to be. If you do "top -b" (so the list is not truncated) and save it to a file, do you get a snapshot that is still unreasonable from your POV? Can you share a concrete example? For FreeBSD showing the values more like you expect I'd blame that on clang/ llvm being slow, but I'll be shot for this remark :-) But still specualting without data: one thing that could make a serious difference is the device you are running your build.sh on having a suboptimal driver spending a lot of cpu in the kernel for the IO the build produces. Martin
