Andrew Theurer wrote:
Avi Kivity wrote:
What's the typical I/O load (disk and network bandwidth) while the
tests are running?
This is average thrgoughput:
network: Tx: 79 MB/sec Rx: 5 MB/sec
MB as in Byte or Mb as in bit?
disk: read: 17 MB/sec write: 40 MB/sec
This could definitely cause the extra load, especially if it's many
small requests (compared to a few large ones).
The host hardware:
A 2 socket, 8 core Nehalem with SMT, and EPT enabled, lots of disks,
4 x
1 GB Ethenret
CPU time measurements with SMT can vary wildly if the system is not
fully loaded. If the scheduler happens to schedule two threads on a
single core, both of these threads will generate less work compared
to if they were scheduled on different cores.
Understood. Even if at low loads, the scheduler does the right thing
and spreads out to all the cores first, once it goes beyond 50% util,
the CPU util can climb at a much higher rate (compared to a linear
increase in work) because it then starts scheduling 2 threads per
core, and each thread can do less work. I have always wanted
something which could more accurately show the utilization of a
processor core, but I guess we have to use what we have today. I will
run again with SMT off to see what we get.
On the other hand, without SMT you will get to overcommit much faster,
so you'll have scheduling artifacts. Unfortunately there's no good
answer here (except to improve the SMT scheduler).
Yes, it is. If there is a lot of I/O, this might be due to the
thread pool used for I/O.
I have a older patch which makes a small change to posix_aio_thread.c
by trying to keep the thread pool size a bit lower than it is today.
I will dust that off and see if it helps.
Really, I think linux-aio support can help here.
Yes, there is a scheduler tracer, though I have no idea how to
operate it.
Do you have kvm_stat logs?
Sorry, I don't, but I'll run that next time. BTW, I did not notice a
batch/log mode the last time I ram kvm_stat. Or maybe it was not
obvious to me. Is there an ideal way to run kvm_stat without a curses
like output?
You're probably using an ancient version:
$ kvm_stat --help
Usage: kvm_stat [options]
Options:
-h, --help show this help message and exit
-1, --once, --batch run in batch mode for one second
-l, --log run in logging mode (like vmstat)
-f FIELDS, --fields=FIELDS
fields to display (regex)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
