[Arm-dev] Gigabyte MP30-AR0

[Gordan Bobic]

On 2016-03-15 22:12, Richard W.M. Jones wrote:
> On Tue, Mar 15, 2016 at 07:49:22PM +0000, Gordan Bobic wrote:
>> On 2016-03-15 18:32, Richard W.M. Jones wrote:
>> >I may be missing some context here, but is there some reason not to
>> >just use a VM?
>> 
>> Performance for one.
> 
> Can you precisely quantify that?

On ARM? No, haven't tried it yet. On x86-64? Between 30% and 40%
on a concurrent load saturating the CPU. Measured with different
hypervisors (KVM, Xen and ESXi) and different generations of
Intel CPUs from Core2 to Westmere Xeons. The results are reproducible
on different loads, from a simple parallel kernel compile to a
parallel read-only replay of MySQL general log.

Here are some old results on Core2 class hardware:
https://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

Unfortunately, later version of both hypervisors and hardware
(I last ran similar tests using MySQL last year), exhibit the
exact same performance degradation.

To reproduce:
1) 1 host, 1 VM
2) Give the VM all CPU cores available on the host
3) Run test with double the number of threads as there are CPU cores
4) If you are running the kernel compile test, put the sources on
tmpfs (yes, you'll need a suitable amount of RAM) to avoid any I/O
bottlenecking

>> >It's more predictable because you'll be running the
>> >same kernel that the 32 bit environment is expecting.
>> 
>> The aarch64 environment seems no less predictable with a
>> kernel defaulting to 4K pages.
> 
> It's more predictable for the 32 bit guest, because the guest will
> have exactly the kernel it expects, not some random kernel and a
> chroot.

Given it's an EL6 armv5tel guest, I dare say there is no reasonable
expectation of any particular kernel from the guest userspace. Sadly,
in the ARM world until very recently, the kernel that ships with the
device has often been the only option.

The only kernel/userspace compatibility issue I have encountered was
on the EL7 ARM port where a recent kernel is required specifically
because systemd has done away with firmware loader helpers, and kernels
before a certain version weren't up to the task of loading the firmware
unassisted. But that's about it. I have a whole stack of ARM devices
running rag-tag kernels they shipped with but with my own userspace.

>> There are also other reasons, for example I want to run ZFS on the
>> host and don't want to have to re-export the shares to guests via a
>> network file system.
> 
>> > Also it will
>> > (or should) work without you needing to compile your own host kernel.
>> 
>> Well, as far as the host kernel is concerned:
>> 
>> 1) I already posted a link with a selection of posts from Linus 
>> himself
>> explaining at some length why using large default pages is a bad idea
>> at the best of times (and for all other cases where bigger pages do 
>> give
>> us that 3% speed-up we can use hugepages directly instead).
>> 
>> 2) The kernel that ships is deprecated and was never a LT kernel 
>> (4.2).
>> 
>> So switching to the next LT kernel better configured for practically
>> any task seems advantageous in every way.
> 
> I think RHELSA 7.3 will have a 4.5 kernel.  Of course "LT" kernels
> aren't really relevant for Red Hat, because we spend huge amounts of
> money supporting our kernels long term.

Let's not go there:
https://bugzilla.redhat.com/show_bug.cgi?id=773107

Gordan