On 20/04/15 07:13, Antti Kantee wrote:
On 20/04/15 01:36, Andrew Stuart wrote:
Incidentally there might be a hint of why this is happening in the
time of 3648.3 show as a result of the xl list, which was done AFTER
the benchmarks had run. Assuming this is Xen reporting the something
like the processing time of each VM then it looks like rumprun is
doing alot of processing relative to the other configurations.
That might be a good catch. Last night I was tracking down some bug on
-baremetal, and noticed that threads which should be sleeping still get
scheduled. Then I got distracted by the Finnish parliament elections.
But I'll definitely look at it today. nb. /xen and /baremetal don't yet
share the same scheduler code, but given that the /baremetal bug I was
tracking was triggered when I was trying to make the scheduler code the
same so that I could merge it, it's a good bet that there's a similar
problem on /xen.
Please pull and try again to see if the performance improves and/or if
the time usage goes down.
