On 20.08.2012 13:25, Doug Barton wrote:
On 08/20/2012 02:59, Alexander Motin wrote:
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.
Yes, I get that, but thanks for making it clear.
Choice is provided because
they are indeed different and none is perfect.
... which is why I'm asking you to stop making them more the same until
we get a better idea of what the issues are.
I have no plans to converge them. I've just found problem in ULE, that
was replicated into 4BSD and it would be strange to fix one without
another. But fixing it exposed another old problem specific to 4BSD,
which I fixed reusing logically equivalent code from ULE. I saw no
reason to reinvent a wheel there, same as to not fix obvious bug. Sure,
it can change behavior in some way, but ULE is not guilty.
--
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"
