Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Sep 2009 13:09:40 -0700
From:      "Matthew Fleming" <matthew.fleming@isilon.com>
To:        "Kostik Belousov" <kostikbel@gmail.com>, "Zachary Loafman" <zml@freebsd.org>
Cc:        svn-src-stable@freebsd.org, svn-src-stable-7@freebsd.org
Subject:   RE: svn commit: r197652 - stable/7/sys/kern
Message-ID:  <06D5F9F6F655AD4C92E28B662F7F853E03171462@seaxch09.desktop.isilon.com>
In-Reply-To: <20090930195254.GK3130@deviant.kiev.zoral.com.ua>
References:  <200909301940.n8UJep9X024249@svn.freebsd.org> <20090930195254.GK3130@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
> >   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 ?

I can't say definitively there's not a bug on HEAD of some kind, but
when I ran a CPU hog and looked at the output of top(1), on HEAD the hog
was listed as near 100%, and on stable/7 it was listed as 0% after a few
seconds for the system to settle.  Since the code looked at least
somewhat different and the bug did not reproduce on HEAD, I assumed it
was only a problem on stable/7.  I had to run HEAD code in a virtual
machine, perhaps this made a difference?

>From a code inspection standpoint, I don't see anything obvious.  On
stable/7, the set of ts_ltick in tdq_runq_rem() appears to be the reason
a cpu hog was not getting incremented by sched_tick().  On HEAD this set
is moved to sched_choose().

Thanks,
matthew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06D5F9F6F655AD4C92E28B662F7F853E03171462>