On 26.11.2012 00:36, Andriy Gapon wrote:
on 25/11/2012 19:57 Andriy Gapon said the following:
on 24/11/2012 00:17 Alex Chistyakov said the following:
I collected two samples and put them here: http://1888.spb.ru/samples.zip
sched-cpu0.ktr is for a VM running on CPU #0 and sched-cpu1.ktr is for
a VM running on CPU #1
They seem to be very different.
It looks like you didn't stop ktr tracing before running ktrdump or something
like that. schedgraph can not grok the files because it believes that the
timestamps are incorrect.
# - While the workload is continuing (i.e. before it finishes), disable
# KTR tracing by setting 'sysctl debug.ktr.mask=0'. This is necessary
# to avoid a race condition while running ktrdump, i.e. the KTR ring buffer
# will cycle a bit while ktrdump runs, and this confuses schedgraph because
# the timestamps appear to go backwards at some point.
Hmm, looks like this assessment is not correct.
I now think that the root cause of schedgraph issue might be a too wild
difference in what TSC counters produce on different (logical/physical) CPUs.
E.g.:
131059 1 33232414877586 ...
131058 1 33232414876546 ...
131057 3 33232416064514 ...
131056 3 33232416064198 ...
Or even:
131038 0 33232862369416 ...
131037 3 33232409671570 ...
131036 0 33232862367256 ...
131035 3 33232409670982 ...
That's 455111586 ticks!
I've tried to calculate those offsets manually to make schedgraph happy.
It seems that while running on one CPU VirtualBox consumes all the CPU
time but behaves different on another CPU. I am not sure how it is
related to scheduler or specific CPUs. My only guess that there is some
unexpected synchronization happens that makes VirtualBox to do some
extra spinning.
--
Alexander Motin
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
