Arm-dev January 2017

arm-dev@lists.centos.org

20 participants
27 discussions

Kernel update
by Nicolas Repentin 11 Jan '17

11 Jan '17

Hi all, I'm using the 7.3 release on my Bananapi. I still using kernel 4.2, and on the updates, I saw the 4.4.26. But, my /boot is quite little (~500MB), and I saw the update want to install the 4.4.12 too : ================================================================================================================================================================================ Package Architecture Version Dépôt Taille ================================================================================================================================================================================ Installation : kernel armv7hl 4.4.26-201.el7 centos-kernel 80 k kernel-core armv7hl 4.4.26-201.el7 centos-kernel 18 M kernel-modules armv7hl 4.4.26-201.el7 centos-kernel 11 M Installation pour dépendances : kernel-core armv7hl 4.4.12-301.el7 centos-kernel 18 M Résumé de la transaction ================================================================================================================================================================================ Installation 3 Paquets (+1 Paquet en dépendance) Is it normal? Is it gonna fit on my /boot? Actually quite used already by the running kernel: [root@atlas /]# df -h /boot/ Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/mmcblk0p1 477M 223M 231M 50% /boot Thanks

2 2

RPI3 and Gnome
by Paul R. Ganci 08 Jan '17

08 Jan '17

I am playing around with making a "desktop" workstation out of a Raspberry PI3 using the armv7hl CentOS. I have had no problems installing the OS and pretty much have everything working except a Gnome desktop. I did: > yum groupinstall "GNOME Desktop" and from what I can tell everything necessary is installed. However when I try to start X up I see it try and start, the display blinks as if everything is good and then drops back down to the console. The log file shown below shows a single error ([ 2665.952] (EE) AIGLX: reverting to software rendering). [ 2665.710] X.Org X Server 1.17.2 Release Date: 2015-06-16 [ 2665.725] X Protocol Version 11, Revision 0 [ 2665.731] Build Operating System: 4.5.7-fedora-4 [ 2665.736] Current Operating System: Linux centos-rpi3 4.4.33-v7.1.el7 #1 SMP Mon Nov 21 18:48:06 UTC 2016 armv7l [ 2665.736] Kernel command line: 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1872 bcm2708_fb.fbheight=1168 bcm2709.boardrev=0xa22082 bcm2709.serial=0x54bd9ed0 smsc95xx.macaddr=B8:27:EB:BD:9E:D0 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 elevator=deadline rootwait selinux=1 security=selinux enforcing=0 [ 2665.756] Build Date: 09 November 2016 05:46:31PM [ 2665.763] Build ID: xorg-x11-server 1.17.2-22.el7 [ 2665.769] Current version of pixman: 0.34.0 [ 2665.783] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 2665.783] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 2665.812] (==) Log file: "/var/log/Xorg.1.log", Time: Sat Dec 31 20:08:58 2016 [ 2665.819] (==) Using config file: "/etc/X11/xorg.conf" [ 2665.827] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 2665.828] (==) ServerLayout "Default Layout" [ 2665.828] (**) |-->Screen "Screen0" (0) [ 2665.828] (**) | |-->Monitor "Monitor0" [ 2665.829] (**) | |-->Device "VideocoreIV" [ 2665.829] (**) |-->Input Device "Keyboard0" [ 2665.829] (==) Automatically adding devices [ 2665.829] (==) Automatically enabling devices [ 2665.830] (==) Automatically adding GPU devices [ 2665.830] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 2665.830] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 2665.830] (==) ModulePath set to "/usr/lib/xorg/modules" [ 2665.830] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 2665.830] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 2665.830] (WW) Disabling Keyboard0 [ 2665.830] (II) Loader magic: 0x54cf7004 [ 2665.830] (II) Module ABI versions: [ 2665.830] X.Org ANSI C Emulation: 0.4 [ 2665.830] X.Org Video Driver: 19.0 [ 2665.830] X.Org XInput driver : 21.0 [ 2665.830] X.Org Server Extension : 9.0 [ 2665.831] (II) no primary bus or device found [ 2665.831] (II) LoadModule: "glx" [ 2665.832] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 2665.855] (II) Module glx: vendor="X.Org Foundation" [ 2665.855] compiled for 1.17.2, module version = 1.0.0 [ 2665.855] ABI class: X.Org Server Extension, version 9.0 [ 2665.855] (==) AIGLX enabled [ 2665.855] (II) LoadModule: "fbdev" [ 2665.856] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 2665.857] (II) Module fbdev: vendor="X.Org Foundation" [ 2665.857] compiled for 1.17.2, module version = 0.4.3 [ 2665.857] Module class: X.Org Video Driver [ 2665.857] ABI class: X.Org Video Driver, version 19.0 [ 2665.857] (II) FBDEV: driver for framebuffer: fbdev [ 2665.857] (++) using VT number 1 [ 2665.857] (WW) Falling back to old probe method for fbdev [ 2665.857] (II) Loading sub module "fbdevhw" [ 2665.857] (II) LoadModule: "fbdevhw" [ 2665.858] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 2665.859] (II) Module fbdevhw: vendor="X.Org Foundation" [ 2665.859] compiled for 1.17.2, module version = 0.0.2 [ 2665.859] ABI class: X.Org Video Driver, version 19.0 [ 2665.859] (II) FBDEV(0): using default device [ 2665.859] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 2665.860] (**) FBDEV(0): Depth 24, (--) framebuffer bpp 32 [ 2665.860] (==) FBDEV(0): RGB weight 888 [ 2665.860] (==) FBDEV(0): Default visual is TrueColor [ 2665.860] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0) [ 2665.860] (II) FBDEV(0): hardware: BCM2708 FB (video memory: 8541kB) [ 2665.860] (II) FBDEV(0): checking modes against framebuffer device... [ 2665.860] (II) FBDEV(0): mode "1920x1200" not found [ 2665.860] (II) FBDEV(0): mode "1600x1200" ok [ 2665.860] (II) FBDEV(0): mode "1280x1024" ok [ 2665.860] (II) FBDEV(0): mode "1152x864" ok [ 2665.860] (II) FBDEV(0): mode "1024x768" ok [ 2665.861] (II) FBDEV(0): mode "800x600" ok [ 2665.861] (II) FBDEV(0): mode "720x400" ok [ 2665.861] (II) FBDEV(0): mode "640x480" ok [ 2665.861] (II) FBDEV(0): checking modes against monitor... [ 2665.861] (--) FBDEV(0): Virtual size is 1600x1200 (pitch 1600) [ 2665.861] (**) FBDEV(0): Default mode "1600x1200": 162.0 MHz (scaled from 0.0 MHz), 75.0 kHz, 60.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0 kHz, 60.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "1152x864": 108.0 MHz (scaled from 0.0 MHz), 67.5 kHz, 75.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "800x600": 36.0 MHz (scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz [ 2665.861] (II) FBDEV(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d) [ 2665.862] (**) FBDEV(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz [ 2665.862] (II) FBDEV(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz d) [ 2665.862] (**) FBDEV(0): Display dimensions: (518, 324) mm [ 2665.862] (**) FBDEV(0): DPI set to (78, 94) [ 2665.862] (II) Loading sub module "fb" [ 2665.862] (II) LoadModule: "fb" [ 2665.863] (II) Loading /usr/lib/xorg/modules/libfb.so [ 2665.864] (II) Module fb: vendor="X.Org Foundation" [ 2665.864] compiled for 1.17.2, module version = 1.0.0 [ 2665.865] ABI class: X.Org ANSI C Emulation, version 0.4 [ 2665.865] (**) FBDEV(0): using shadow framebuffer [ 2665.865] (II) Loading sub module "shadow" [ 2665.865] (II) LoadModule: "shadow" [ 2665.865] (II) Loading /usr/lib/xorg/modules/libshadow.so [ 2665.865] (II) Module shadow: vendor="X.Org Foundation" [ 2665.865] compiled for 1.17.2, module version = 1.1.0 [ 2665.866] ABI class: X.Org ANSI C Emulation, version 0.4 [ 2665.866] (==) Depth 24 pixmap format is 32 bpp [ 2665.892] (==) FBDEV(0): Backing store enabled [ 2665.894] (**) FBDEV(0): DPMS enabled [ 2665.894] (==) RandR enabled [ 2665.945] (II) SELinux: Disabled by boolean [ 2665.952] (II) AIGLX: Screen 0 is not DRI2 capable [ 2665.952] (EE) AIGLX: reverting to software rendering [ 2665.998] (II) AIGLX: Loaded and initialized swrast [ 2665.998] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 2666.260] (II) config/udev: Adding input device CM Storm QuickFire Rapid keyboard (/dev/input/event0) [ 2666.260] (**) CM Storm QuickFire Rapid keyboard: Applying InputClass "evdev keyboard catchall" [ 2666.260] (II) LoadModule: "evdev" [ 2666.261] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 2666.263] (II) Module evdev: vendor="X.Org Foundation" [ 2666.263] compiled for 1.17.2, module version = 2.9.2 [ 2666.264] Module class: X.Org XInput Driver [ 2666.264] ABI class: X.Org XInput driver, version 21.0 [ 2666.264] (II) Using input driver 'evdev' for 'CM Storm QuickFire Rapid keyboard' [ 2666.264] (**) CM Storm QuickFire Rapid keyboard: always reports core events [ 2666.264] (**) evdev: CM Storm QuickFire Rapid keyboard: Device: "/dev/input/event0" [ 2666.264] (--) evdev: CM Storm QuickFire Rapid keyboard: Vendor 0x2516 Product 0x4 [ 2666.265] (--) evdev: CM Storm QuickFire Rapid keyboard: Found keys [ 2666.265] (II) evdev: CM Storm QuickFire Rapid keyboard: Configuring as keyboard [ 2666.265] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/0003:2516:0004.000E/input/input13/event0" [ 2666.265] (II) XINPUT: Adding extended input device "CM Storm QuickFire Rapid keyboard" (type: KEYBOARD, id 6) [ 2666.265] (**) Option "xkb_rules" "evdev" [ 2666.270] (II) config/udev: Adding input device CM Storm QuickFire Rapid keyboard (/dev/input/event1) [ 2666.270] (**) CM Storm QuickFire Rapid keyboard: Applying InputClass "evdev keyboard catchall" [ 2666.270] (II) Using input driver 'evdev' for 'CM Storm QuickFire Rapid keyboard' [ 2666.270] (**) CM Storm QuickFire Rapid keyboard: always reports core events [ 2666.270] (**) evdev: CM Storm QuickFire Rapid keyboard: Device: "/dev/input/event1" [ 2666.271] (--) evdev: CM Storm QuickFire Rapid keyboard: Vendor 0x2516 Product 0x4 [ 2666.271] (--) evdev: CM Storm QuickFire Rapid keyboard: Found keys [ 2666.271] (II) evdev: CM Storm QuickFire Rapid keyboard: Configuring as keyboard [ 2666.271] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:2516:0004.000F/input/input14/event1" [ 2666.271] (II) XINPUT: Adding extended input device "CM Storm QuickFire Rapid keyboard" (type: KEYBOARD, id 7) [ 2666.271] (**) Option "xkb_rules" "evdev" [ 2666.623] (II) evdev: CM Storm QuickFire Rapid keyboard: Close [ 2666.623] (II) UnloadModule: "evdev" [ 2666.623] (II) evdev: CM Storm QuickFire Rapid keyboard: Close [ 2666.623] (II) UnloadModule: "evdev" [ 2666.703] (II) Server terminated successfully (0). Closing log file. I used this /etc.X11/xorg.conf: Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "Device" Identifier "VideocoreIV" VendorName "Broadcom" BoardName "RPI3Graphics" Driver "fbdev" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Dell" ModelName "Ultrasharp U2410" DisplaySize 518 324 HorizSync 30.0 - 81.0 VertRefresh 56.0 - 75.0 Option "DPMS" EndSection Section "Screen" Identifier "Screen0" Device "VideocoreIV" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1920x1200" "1600x1200" "1280x1024" "1152x864" "1024x768" "800x600" "720x400" "640x480" EndSubSection EndSection Does anybody see what I am doing wrong? Like I said it looks like the desktop wants to startup but then just crashes. Thanks for your help. -- Paul (ganci(a)nurdog.com) Cell: (303)257-5208

2 3

Release for CentOS 7.3.1611 on ARM64/AArch64
by Jim Perrin 05 Jan '17

05 Jan '17

I am pleased to announce the general availability of CentOS Linux 7 (1611) for AArch64/ARM64 machines. == Changes The kernel has been rebased from 4.2.0 to 4.5.0, and includes several patches recently merged into the upstream. The kernel patches and modifications can be found at https://git.centos.org/summary/sig-altarch!kernel.git in the sig-altarch7-aarch64 branch. == Download You can download new images and isos via http://mirror.centos.org/altarch/7/isos/aarch64/ Images and sha256sums: 1513f5325accfd32ac7973a9b24e401c829ece24da78e24d021e507e877f930e CentOS-7-aarch64-Everything.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64.img.xz 48776338f8c8994a9499f07e3af847253cf7235c6aac635a8418a2028ec675cf CentOS-7-aarch64-NetInstall.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64-rolling.img.xz 238b1ebf22a0ff894064e6ed2ac35ee02a6503657a40ad51f2eee7afc8229e75 CentOS-7-aarch64-rootfs-7.3.1611.tar.xz == Known Issues 1. Mustang based boards must be on the most recent firmware version, otherwise the network may lose connectivity when using 4.5.0-19+ based kernels. Please ensure your hardware is running the most recent firmware available to avoid network issues. 2. Merlin based boards should be on the most recent firmware version, in order to take full advantage of recent kernel improvements. 3. Some ThunderX based boards have been reported to have MAC address inconsistency when using older firmware versions. Please make sure you have the most recent firmware applied to your hardware to avoid network issues. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

3 5

Fwd: Golang Performance
by Gordan Bobic 05 Jan '17

05 Jan '17

The --cpuprofile option doesn't seem to generate a human-readable file and my go-fu is weak, but I've attached it anyway. On Tue, Jan 3, 2017 at 9:18 PM, Jeremy Linton <jlinton(a)redhat.com> wrote: > Hi, > > On 01/01/2017 11:57 AM, Gordan Bobic wrote: > >> I'm not much of a Go user at the best of times, but I am noticing that >> there seems to be a huge ( > 10x clock-for-clock) performance >> discrepancy between x86-64 and aarch64 binaries. >> >> Specific example I am looking at is rclone, uploading encryoted backups >> to Amazon Cloud Drive. >> >> When I run it on a Westmere class Xeon (3.6GHz), it is comsuming about >> 2% CPU to saturate a 20Mbit uplink. When I run it on an X-Gene (2.0GHz), >> it is consuming about 50% CPU. Even adjusting for differences in clock >> speeds, this seems to be a huge difference. >> >> Is the Go complier known to produce very poor results on aarch64, or is >> something else in play? I know that x86-64 has a much more powerful SIMD >> unit, but I am not convinced that this is the explanation, and rclone >> doesn't use AES AFAIK, so hardware implementation of that doesn't seem >> to explain it either. >> > > AFAIK, amazon drive uses SSL/TLS so its likely you are using AES. Further, > go implements their own TLS/etc libraries rather than depending on > openSSL/gnuTLS. So, while ARMv8 cores have hardware AES instructions, go's > AES implementation is currently only hardware accelerated on x86 and s390. > MD5 (also used AFAIK) is also missing an ARM64 native implementation even > though there is an ARM one. So, just those two issues could cause a large > performance delta, but at those data rates it seems possible there is > something else going on. > > So, a couple questions, did you build rclone yourself or use one of the > binaries from rclone.org? > > There is a --cpuprofile option to rclone. It might be helpful if you can > post the output from that. > > Thanks, > > > >> At general purpose pointer chasing such as compiling, the X-Gene seems >> to produce similar performance clock-for-clock as the Westmere Xeon, so >> the large discrepancy with rclone seems odd. >> >> Has anyone got any insights? Both machines are running CentOS 7. >> >> Gordan >> >> >> _______________________________________________ >> Arm-dev mailing list >> Arm-dev(a)centos.org >> https://lists.centos.org/mailman/listinfo/arm-dev >> >> > _______________________________________________ > Arm-dev mailing list > Arm-dev(a)centos.org > https://lists.centos.org/mailman/listinfo/arm-dev >

2 1

[PATCH] PCI/ASPM: Don't retrain link if ASPM not possible.
by Vadim Lomovtsev 04 Jan '17

04 Jan '17

From: David Daney <david.daney(a)cavium.com> Some (defective) PCIe devices are not able to reliably do link retraining. Check to see if ASPM is possible between link partners before configuring common clocking, and doing the resulting link retraining. If ASPM is not possible, there is no reason to risk losing access to a device due to an unnecessary link retraining. Signed-off-by: David Daney <david.daney(a)cavium.com> Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev(a)caviumnetworks.com> --- drivers/pci/pcie/aspm.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c index 2dfe7fd..abad79e 100644 --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -351,12 +351,26 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist) return; } + /* Get upstream/downstream components' register state */ + pcie_get_aspm_reg(parent, &upreg); + child = list_entry(linkbus->devices.next, struct pci_dev, bus_list); + pcie_get_aspm_reg(child, &dwreg); + + /* + * If ASPM not supported, don't mess with the clocks and link, + * bail out now. + */ + if (!(upreg.support & dwreg.support)) + return; + /* Configure common clock before checking latencies */ pcie_aspm_configure_common_clock(link); - /* Get upstream/downstream components' register state */ + /* + * Re-read upstream/downstream components' register state + * after clock configuration + */ pcie_get_aspm_reg(parent, &upreg); - child = list_entry(linkbus->devices.next, struct pci_dev, bus_list); pcie_get_aspm_reg(child, &dwreg); /* -- 2.5.5

2 2

[PATCH] Add ConnectX-4 Ethernet support
by Christopher Covington 04 Jan '17

04 Jan '17

Enable Ethernet mode for the Mellanox ConnectX-4 (mlx5 driver), which some users may choose as a high-speed network interface. Signed-off-by: Christopher Covington <cov(a)codeaurora.org> --- SOURCES/config-centos-sig | 1 + SPECS/kernel-aarch64.spec | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/SOURCES/config-centos-sig b/SOURCES/config-centos-sig index 7cb8462..20bab07 100644 --- a/SOURCES/config-centos-sig +++ b/SOURCES/config-centos-sig @@ -10,3 +10,4 @@ CONFIG_I2C_DESIGNWARE_CORE=m CONFIG_I2C_DESIGNWARE_PLATFORM=m CONFIG_I2C_DESIGNWARE_PCI=m CONFIG_THUNDER_NIC_RGX=m +CONFIG_MLX5_CORE_EN=y diff --git a/SPECS/kernel-aarch64.spec b/SPECS/kernel-aarch64.spec index d510657..f781578 100644 --- a/SPECS/kernel-aarch64.spec +++ b/SPECS/kernel-aarch64.spec @@ -12,7 +12,7 @@ Summary: The Linux kernel %define rpmversion 4.5.0 %define pkgrelease 15.el7 -%define centupdate 19.el7 +%define centupdate 20.el7 # allow pkg_release to have configurable %{?dist} tag %define specrelease %%SPECRELEASE%% @@ -1500,6 +1500,9 @@ fi %kernel_variant_files %{with_debug} kernel-debug debug %changelog +* Tue Dec 13 2016 Christopher Covington <cov(a)codeaurora.org> [4.5.0-20.el7] +- Add Mellanox ConnectX-4 Ethernet support + * Mon Nov 21 2016 Jim Perrin <jperrin(a)centos.org> [4.5.0-19.el7] - Add various ThunderX patches from arm-dev list. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

2 1

Golang Performance
by Gordan Bobic 03 Jan '17

03 Jan '17

I'm not much of a Go user at the best of times, but I am noticing that there seems to be a huge ( > 10x clock-for-clock) performance discrepancy between x86-64 and aarch64 binaries. Specific example I am looking at is rclone, uploading encryoted backups to Amazon Cloud Drive. When I run it on a Westmere class Xeon (3.6GHz), it is comsuming about 2% CPU to saturate a 20Mbit uplink. When I run it on an X-Gene (2.0GHz), it is consuming about 50% CPU. Even adjusting for differences in clock speeds, this seems to be a huge difference. Is the Go complier known to produce very poor results on aarch64, or is something else in play? I know that x86-64 has a much more powerful SIMD unit, but I am not convinced that this is the explanation, and rclone doesn't use AES AFAIK, so hardware implementation of that doesn't seem to explain it either. At general purpose pointer chasing such as compiling, the X-Gene seems to produce similar performance clock-for-clock as the Westmere Xeon, so the large discrepancy with rclone seems odd. Has anyone got any insights? Both machines are running CentOS 7. Gordan

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev January 2017