Re: Initial 6.1 questions

Danial Thom wrote:

--- Robert Watson <rwatson@xxxxxxxxxxx> wrote:


On Tue, 13 Jun 2006, Danial Thom wrote:


Maybe someone can explain this output. The

top line shows 99.6%idle. Is it

just showing CPU 0s stats on the top line?

Two types of measurements are taken: sampled
ticks regarding whether the system as a while is in {user, nice, system,
intr, idle}, and then sampling for individual processes. Right now, the
system measurements are kept in a simple array of tick counters called cp_time. John Baldwin and others have changes that make these tick counters per-CPU. The lines at the top of top(1)'s output are derived from those tick
counters. Ticks are measured on each CPU, so those are a summary across all
CPUs. To add cpustat support, we need to merge John's patch to make cp_time
per-CPU (ie., different counters for different CPUs) and teach the userland
tools to retrieve them. When you run top you'll notice that it adjusts the
measurements each refresh. In effect, what it's doing is sampling the change
in tick counts over the window, pulling down the new values and calculating the
percentages of ticks in each "bucket" in the last window.


That doesn't explain why the Top line shows 99.6%
idle, but the cpu idle threads are showing
significant usage.

I'm getting a constant 6000 Interrupts / Second
on my em controller, yet top jumps all over the
place; sitting at 99% idle for 10 seconds, then
jumping to 50%, then somewhere in between. It
seems completely unreliable. The load I'm
applying is constant.

DT

Be aware that there was a significant change made to if_em
in 7-CURRENT in Jan 2006 to improve load performance. It'll
probably get backported for 6.2, but you might consider
looking at it before you make up your mind on 6.1 performance.

Sscott

_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • [patch 18/22] dynticks: core
    ... This is an extension to the per-cpu sched_tick timer of the high resolution ... before going idle, when no timer events are due in the next tick. ...
    (Linux-Kernel)
  • [patch 14/19] dynticks: core code
    ... This is an extension to the per-cpu sched_tick timer of the high resolution ... before going idle, when no timer events are due in the next tick. ...
    (Linux-Kernel)
  • [patch 17/21] dynticks: core
    ... This is an extension to the per-cpu sched_tick timer of the high ... The periodic tick is resumed when the CPU leaves the ... idle state. ...
    (Linux-Kernel)
  • [patch 36/46] tick-management: dyntick / highres functionality
    ... Add functions to provide dynamic ticks and high resolution timers. ... The code which keeps track of jiffies and handles the long idle ... +static inline void tick_clock_notify ... Periodic tick ...
    (Linux-Kernel)
  • Re: Initial 6.1 questions
    ... system measurements are kept in a simple array of tick counters called cp_time. ... Ticks are measured on each CPU, so those are a summary across all ...
    (freebsd-performance)