On 20.08.2012 11:32, Doug Barton wrote:
On 08/15/2012 03:18, Alexander Motin wrote:
On 15.08.2012 03:09, Doug Barton wrote:
On 08/14/2012 12:20 PM, Adrian Chadd wrote:
Would you be willing to compile a kernel with KTR so you can capture
some KTR scheduler dumps?
That way the scheduler peeps can feed this into schedgraph.py (and you
can too!) to figure out what's going on.
Maybe things aren't being scheduled correctly and the added latency is
killing performance?
You might also try switching to SCHED_ULE to see if it helps.
Although, in the last few months as mav has been converging the 2 I've
started to see the same problems I saw on my desktop systems previously
re-appear even using ULE. For example, if I'm watching an AVI with VLC
and start doing anything that generates a lot of interrupts (like moving
large quantities of data from one disk to another) the video and sound
start to skip. Also, various other desktop features (like menus, window
switching, etc.) start to take measurable time to happen, sometimes
seconds.
... and lest you think this is just a desktop problem, I've seen the
same scenario on 8.x systems used as web servers. With ULE they were
frequently getting into peak load situations that created what I called
"mini thundering herd" problems where they could never quite get caught
up. Whereas switching to 4BSD the same servers got into high-load
situations less often, and they recovered on their own in minutes.
It is quite pointless to speculate without real info like mentioned
above KTR_SCHED traces.
I'm sorry, you're quite wrong about that. In the cases I mentioned, and
in about 2 out of 3 of the cases where users reported problems and I
suggested that they try 4BSD, the results were clear. This obviously
points out that there is a serious problem with ULE, and if I were the
one who was responsible for that code I would be looking at ways of
helping users figure out where the problems are. But that's just me.
I am not telling anything bad about 4BSD. Choice is provided because
they are indeed different and none is perfect. 4BSD also has problems.
What I would like to say is that if we want to improve situation, we
need more detailed info then just verbal description. I am not telling
that ULE is perfect. I went there because I've seen problems, and I am
still fixing some pieces. I am just trying to explain described behavior
from the point of my knowledge about it, hoping that it may help
somebody to set up some new experiments or try some tuning/fixing.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
