On 12/22/2017 01:18 PM, George Dunlap wrote: > On Fri, Dec 22, 2017 at 10:41 AM, Sergej Proskurin > <prosku...@sec.in.tum.de> wrote: >> Hi George, >> >> Thank you for your reply. >> >> On 12/22/2017 11:26 AM, George Dunlap wrote: >>> On Thu, Dec 21, 2017 at 2:42 PM, Sergej Proskurin >>> <prosku...@sec.in.tum.de> wrote: >>>> Hi all, >>>> >>>> For the sake of completeness: the solution to the issue stated in my >>>> last email was deactivating Intel's Turbo Boost technology directly in >>>> UEFI (deactivating Turbo Boost through xenpm was not enough). Apparently >>>> Turbo Boost affects Linux and KVM differently than Xen, which led to the >>>> phonomenon, in which the benchmark execution on Xen appeared faster than >>>> on bare metal. >>> >>> *Appeared* faster than on bare metal, or *was* faster than on bare metal? >>> >>> If the source of the change was the Turbo Boost, it's entirely >>> possible that the difference is due to the placement of workers on >>> cpus -- i.e., that Linux's bare metal scheduler makes a worse choice >>> for this particular workload than Xen's scheduler does. >>> >> >> Given the fact that for this particular benchmark I configured both dom0 >> and domu to using only one core (in fact I have pinned both domains to >> the same physical core), I do not believe that the performance increase >> was due to a better placement on all available CPU's. However, I >> absolutely agree that there might be a difference in handling Turbo >> Boosts between Linux and Xen. > > in which case, *that* may actually be your problem. :-) > > I've got a "scheduler microbenchmark" program that I wrote that has > unikernel workloads doing simplistic "burn / sleep" cycles. There's a > certain point -- somewhere between 50% busy and 80% busy -- where > adding more work actually *improves* the performance of existing > workloads. Presumably when the cpu is busy more of the time, the > microcode puts it into a higher performance state. > > If you pinned them to different sockets, you might actually get a > result more in line with your expectations. > >
I see your point. Yet, I just ran the benchmark with domu pinned to a different physical core. Unfortunately, the results where the same as before. Nevertheless, it is a good hint, thank you :) Besides, I also believe that if the additional cpu load through dom0 running on the same core would have been the issue, we would experience a similar effect with KVM, as, in my experiment, the guest runs on the same physical core as the underlying Linux host. Thanks, ~Sergej _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
