svn commit: r197652 - stable/7/sys/kern

[Kostik Belousov]

On Wed, Sep 30, 2009 at 07:40:51PM +0000, Zachary Loafman wrote:
> Author: zml
> Date: Wed Sep 30 19:40:51 2009
> New Revision: 197652
> URL: http://svn.freebsd.org/changeset/base/197652
> 
> Log:
>   sched_ule in stable/7 has a bug (introduced in r180607) where a thread
>   that is running often will appear to not be running much at all.
Why is this not a problem on HEAD ?

>   
>   sched_ule has a much less accurate mechanism for determining how much
>   various threads are running.  Every tick, hardclock_cpu() calls
>   sched_tick(), and the currently running thread gets it's ts_ticks
>   incremented.  Whenever an event of interest happens to a thread, the
>   ts_ticks value may be decayed; it's supposed to be a rough running
>   average of the last 10 seconds.  So there's a ts_ltick which is the last
>   tick we looked at decaying ts_ticks.
>   
>   The increment in sched_tick() was slightly buggy on SMP, because a
>   thread could get incremented on two different CPUs in the rare case
>   where it was swapped from one which had run sched_tick() this tick to
>   one which hadn't.  The fix that was used relied on ts_ltick and only
>   incremented ts_ticks if ts_ltick was not from the current tick.
>   This is buggy, because any time the thread began running on a CPU in the
>   current tick, we would have set ts_ltick to ticks, so if it was still
>   running at sched_tick() we wouldn't increment.
>   
>   A system with a single process that hogs the CPU and is otherwise idle,
>   therefore, would look like all threads were at 0%. The threads not
>   running are really at 0%, and the hog is not getting its ts_ticks
>   incremented since it went through some other runq stats that set
>   ts_ltick.  On a 2-way SMP the thread used to get shuffled regularly
>   between CPUs (I think fallout from this bug), so it would appear a
>   little over 50% busy.
>   
>   The fix is to use a separate variable to record when the last
>   sched_tick() increment happened.
>   
>   Submitted by:       Matthew Fleming (matthew.fleming at isilon.com)
>   Reviewed by:        zml, dfr
>   Approved by:        dfr (mentor)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-stable-7/attachments/20090930/0296652e/attachment.pgp