AArch64 masaüstü deneyinin sonu

 (marcin.juszkiewicz.com.pl)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yaklaşık 11 ay boyunca Ampere Altra tabanlı bir AArch64 masaüstü günlük kullanımda kullanıldı, ancak sunucu platformunu masaüstü gibi kullanmanın getirdiği çekirdek, GPU ve uygulama uyumluluğu yükü giderek birikti
  • Sistem Ampere Altra Q80-30 80 çekirdek 3.0GHz, 128GB RAM, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T ve Fedora 42–44 kombinasyonundan oluşuyordu; zaten baştan masaüstü için tasarlanmış bir donanım değildi
  • AMD GPU kullanımı için erratum 82288 / PCIE_65 geçici çözüm yaması gerekiyordu; bu yüzden Fedora çekirdek güncellemelerinde neredeyse her hafta kendi çekirdeğini yeniden derlemek zorunda kaldı
  • Linux 7.0 civarında AMD GPU hataları ve video kare düşmeleri ortaya çıktı; Nvidia RTX 2060'a geçildikten sonra bile AArch64 Flatpak deposunda org.freedesktop.Platform.GL.nvidia bulunmadığı için FreeCAD ve OrcaSlicer çöktü
  • Sonunda x86-64 Ryzen 5 3600 sistemine geri dönüldü; Ampere Altra masaüstü yerine RISC-V paket derleme işi için bırakıldı ve yeni bir AArch64 masaüstü için farklı bir donanım platformu gerektiği sonucuna varıldı

Sunucu sınıfı Altra ile kurulan masaüstü yapılandırması

  • Yaklaşık 11 ay boyunca AArch64 masaüstü günlük kullanımda denendikten sonra deney sonlandırıldı
  • Nihai donanım yapılandırması şöyleydi
    • CPU: Ampere Altra Q80-30, 80 çekirdek 3.0GHz
    • RAM: 128GB, 8×16GB HMA82GR7CJR8N-XN
    • GPU: AMD Radeon RX6700XT
    • NVMe: Lexar LM970 2TB, ADATA SX8200 Pro 1TB
    • Anakart: ASRock Rack ALTRAD8UD-1L2T
    • PSU: MSI MPG A850G 850W
    • Kasa: Endorfy 700 Air
    • USB3: PCIe x4 markasız USB 3.2/10Gbps denetleyici
  • Bu kart sunucu anakartıydı ve Altra sistemi de başlı başına masaüstü için tasarlanmış bir ürün değildi
  • Ampere Altra sisteminin QVL listesinde AMD Radeon GPU kartları yer almıyor; çalıştırmak mümkün olsa da çoğu zaman ek çalışma gerekiyor
  • Ayrı USB 3.2 denetleyici, anakartın yerleşik desteğine kıyasla daha fazla USB aygıtı ve harici NVMe için 10Gbps portlar sağlıyordu
  • Tüm sistem Fedora 42–44 üzerinde çalıştı, ancak fiili kullanım için Fedora'nın varsayılan çekirdeği değil, özel derlenmiş bir çekirdek gerekiyordu

PCIE_65'in yarattığı çekirdek bakım yükü

  • Ampere Altra'nın PCI Express denetleyicisinde erratum 82288 / PCIE_65 sorunu bulunuyor
  • PCIE_65, PCIe MMIO yazmalarında hatalı adres oluşturabiliyor ve özellikle AMD GPU gibi belirli aygıt türlerini etkiliyor
  • Linux çekirdek sürücüsü MMIO alanını ioremap_wc gibi Normal, non-cacheable bellek niteliğiyle eşlediğinde sorun ortaya çıkabiliyor
    • Bunun amacı write combining ya da hizasız erişimi mümkün kılmak olabilir
    • Bu durumda PCIe arayüzünün outbound MMIO write işlemlerinde veri bozulması yaşanabiliyor
    • Geçici çözüm, ioremap_wc yerine ioremap benzeri şekilde Device, non-gathering bellek olarak eşlemek ve PCIe MMIO alanındaki tüm bellek işlemlerini sıkı biçimde hizalamak
  • Sistemi düzgün bir Linux sistemi olarak kullanabilmek için Fedora çekirdek paketi her güncellendiğinde çekirdeği yeniden derlemek gerekiyordu; bu da genellikle haftalık bir işti
  • Yerel Fedora çekirdek paket deposu güncellendikten sonra 7.0.2-200.fc44.pcie65.6 gibi özel sürüm kuralıyla derleme yapılıyordu
    • pcie65, uygulanan yamayı gösteriyordu
    • Son sayı ise yamanın rebase sayacıydı
  • Yamalar GitHub deposundan alınıp rebase ediliyor, gerektiğinde düzenleniyordu; bunun sonucu olarak zaman zaman resmi Fedora'dan daha yeni çekirdek kullanılmış oluyordu

80 çekirdek, masaüstü hissedilen performansı garanti etmiyor

  • 80 CPU çekirdeğine sahip olmak bunun iyi bir masaüstü makinesi olacağı anlamına gelmedi
  • Yüksek çekirdek sayısı, masaüstünde ihtiyaç duyulan hızlı hissedilen performansı garanti etmedi

GPU değişiminden sonra da süren uygulama uyumluluğu sorunları

  • AMD Radeon RX6700XT, out-of-tree PCIE_65 yaması uygulanmış çekirdekte çalışıyordu; oyun çalıştırmak ve donanım hızlandırmalı video çözme de mümkündü
  • Linux 7.0 sürümü civarında bir noktadan sonra AMD GPU başarısız olmaya başladı
    • Oyun çalıştırıldığında amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 günlüğü tekrar tekrar görünüyordu
    • YouTube videolarında 750 karenin 720'si düşüyor, bu da sistemi fiilen kullanılamaz hale getiriyordu
  • Normalde çekirdekte sorunun nerede başladığını bulmak için bisect yapılırdı, ancak PCIE_65 yaması yüzünden çekirdek tainted durumdaydı ve gerçek nedeni ayırt etmek zordu
  • AMD Radeon yerine Nvidia RTX 2060 takıldı
    • nouveau çekirdek sürücüsünü kullanmak için hâlâ PCIE_65 yaması gerekiyordu
    • Fedora'nın varsayılan çekirdeği ile Nvidia ikili sürücüsü birleşimi sorunsuz çalıştı
    • Video çözme hızlandırması ve Wine tabanlı bazı oyunlar da çalıştı
  • FreeCAD ve OrcaSlicer ise açılır açılmaz çöktü
    • Bunun nedeni AArch64 Flatpak deposunda org.freedesktop.Platform.GL.nvidia paketinin bulunmamasıydı
    • Bu iki araç sık kullanılan uygulamalar olduğu için masaüstü geçişini zorlaştıran temel sorun haline geldi

x86-64'e dönüş ve Altra'nın yeni rolü

  • Sonunda kapalı duran x86-64 sistemi yeniden açıldı
  • Çok sayıda kablo taşınıp yeni kablolar da yerleştirildikten sonra, masa altındaki iki sistem birlikte kullanılmaya başlandı
    • wooster: Ampere Altra sistemi
    • puchatek: Ryzen 5 3600 sistemi
  • 80 çekirdekten 6 çekirdek 12 iş parçacığına geçmek garipti, ancak gerçek işler sorunsuz yürüdü
    • Tüm iş parçacıkları kullanılırken bile müzik çalmaya devam ediyordu
    • Steam kütüphanesindeki tüm oyunlar oynanabiliyordu
    • FreeCAD ile ev projesi kasasının tasarımı tamamlanabiliyordu
    • OrcaSlicer ile 3D baskı için prototipler doğrudan hazırlanabiliyordu
  • Ampere Altra sistemi açık bırakılarak RISC-V paket derleme işlerini üstlenmeye devam etti
  • Bu sistem tek iş parçacıklı performansta zayıf olsa da çok çekirdekli yüklerde hızlı çalışıyor

Aynı tür bir AArch64 masaüstü yeniden denenmeyecek

  • Ampere Altra ile aynı masaüstü deneyini tekrarlama planı yok
  • Yeni bir AArch64 masaüstü denemek için tamamen yeni bir donanım platformu gerekiyor
  • Nvidia DGX Spark sistemi satın almak için 20.000 PLN'den fazla harcama planı da yok

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs yorumları

  • Bu duruma bir ölçüde katılıyorum. Benim Raptor Talos II’imde IBM sürekli PowerNV’yi bozuyor.
    Başta sorun amdgpu’ydu, şimdi ise SATA kartı. IBM, bare-metal olmayan sistemler için PCIe ile sürekli oynadığı için 6.14 çekirdeğine takılı kaldım.

    • Hangi Linux dağıtımını kullandığını merak ediyorum. Şirket sunucusu Ubuntu 26.04 üzerinde 7.0 çekirdeğiyle çalışıyor ve destek gayet iyi.
      Çıktığından beri bir tane istemiştim ama artık epey yaşlandı; belki de Power 11 sürümü gelebilir diye düşünüyorum.

  • Ben de benzerini yaşadım. Thinkpad X13S üzerinde NixOS çalıştırmayı denedim; bir ölçüde çalıştı ama kurulumdan itibaren Ubuntu ISO kullanmam gerekti.
    Çünkü düzgün önyüklenen bir aarch64 UEFI NixOS imajı bulamadım. En yeni çekirdek yükseltmesinden sonra önyükleme bozuldu ve artık sistemi sadece çalışır hâle getirmek için harcayacak enerjim kalmadı.
    Ubuntu’da da X13S desteği bir ölçüde var, ama geleneksel bir x86_64 makinede doğal olarak çalışmasını bekleyeceğiniz pek çok şey çalışmıyor. Uyku modu hiç yok, TPM desteği sınırlı, grafikler de tuhaf davranıyor; test edemediğim daha fazla sorun da muhtemelen vardır.
    Üstelik buna Anbernic gibi şirketlerin emülasyon el konsolları gibi yalnızca eski imajların sağlandığı ARM cihazları ya da Clockwork uConsole gibi donanımı akıllıca kullanan veya zorlayan ve standart dışı çekirdek yamaları gerektiren cihazları dahil etmiyorum bile. Sonuçta bu yazılımlar upstream’e giremiyor ve güncellenemeyen bir işletim sistemine sahip donanımlar olarak kalıyorlar.
    Linux’ta ARM’nin iyi çalışmasını umarak birkaç bilgisayarda epey zaman harcadım ama tıkandım. Raspberry Pi dışında “öylece çalışan” bir şey olmadı; donanım/çekirdek tarafını da anlamlı iyileştirmeler yapacak kadar bilmiyorum.

    • Ben de X13S aldım. Boyutu ve ağırlığı mükemmel görünüyordu.
      Aynı şekilde NixOS kurulumu için saatler harcadım; Ubuntu üzerinden kurup bir şekilde çalışır hâle getirdim ama o kadar kırılgandı ki pratikte düzgün kullanmak zordu.
      Gerçekten iyi çalışmasını istiyordum ama Linux tarafında terk edilmiş gibi hissettirdi; sonunda vazgeçip Apple MacBook Air’de NixOS’u sanal makinede çalıştırmaya geçtim.
    • Benim de X13s’im var; denediğim tek dağıtım Fedora oldu ve kurulum programını başlatınca giriş/çıkış kilitlenmesi yaşanıyor. İyi değil.
      Ubuntu’ya da özel bir sevgim olmadığı için başka dağıtımları özellikle denemedim; Windows ise yeterince iyi çalışıyor.
      Daha yeni SoC’lerde tuhaflıklar çok daha az. Örneğin çekirdek komut satırını bir paragraf uzunluğunda girmeniz gerekmiyor. Ama X13s’in X Elite 2 sürümü çıkmadı.

  • Yeni Nvidia RTX Spark dizüstülerinin resmi Linux desteği alıp almayacağını merak ediyorum.
    Sonuçta Ubuntu türevi bir dağıtım çalıştıran DGX Spark ile neredeyse aynı platform, ama şimdiye kadarki işaretler pek iyi görünmüyor.

  • Karşıt bir deneyim olarak, Radxa Rock5bPlus’ı yaklaşık 4 aydır kullanıyorum. 16 GB bellek ve NVMe yapılandırması var; mainline u-boot, Fedora Rawhide’ın EFI sürümü ve mainline çekirdek kullanıyorum.
    Collabora’nın rk3588 desteğini mainline’a taşımak için yaptığı iş gerçekten şaşırtıcı düzeyde.
    Hâlâ beklediğim bazı şeyler var. HDMI 2.0 ve üzeri, yani 4k@60, ayrıca USB-C DP gibi şeyler. Yine de donanım açısından XPS 13 9370’imden daha az tuhaflığı var gibi görünüyor. O dizüstünde 5.14 civarından beri ses çıkışı öylece durdu.
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • OrangePi 5 Plus kullanıyorum ve HDMI yakalamanın artık birleştirildiğini gördüm.
      Henüz HDCP desteği yok, ama daha önce yaptığım düşük gecikmeli 1080p HDMI OSD denemesine dönme zamanı gelmiş gibi.
      3 kare gecikmeyle çalışıyordu; teorik minimum 2 kare. HDMI sinyalinin üstüne Chromium Embedded bindirerek ev medya kurulumunda OSD yeteneklerini ciddi biçimde genişletebiliyordum.
      En büyük sorun kararsızlıktı; tüm kurulum OrangePi çekirdeğini düzenli olarak çökertiyordu.

  • Bu, bence Linux’un donanım desteğinin mevcut durumunu daha iyi gösteriyor. Yalnızca popüler ve kârlı donanımlar çekirdek desteği alıyor; ikili sürücülerin durumu ise eskiden beri hâlâ cehennem.
    İnsanların kendi donanımlarında bir şeyleri çalıştırmak için Linux’un peşinden koşup sonunda eski bir çekirdeğe takılı kalmaları ya da yamaları kendilerinin sürdürüp rebase etmek zorunda kalmaları ilginç. Oysa böyle şeyler yapmadan eski donanımı destekleyen bir işletim sistemi kullanabilirlerdi.

    • Bana bu kusurlu donanımı AMD GPU ile iyi çalıştırmanın yolunu hâlâ arıyorlarmış gibi geliyor.
      Söylenen şu: “Altra ürün ailesi errata’sına göre PCIE_65, PCIe MMIO yazmalarında hatalı adres üretebilir ve belirli cihaz türlerini, özellikle AMD GPU’ları etkiler; bu nedenle Altra ürün ailesi genel olarak bu tür cihazlarla uyumlu değildir. Deney ve geliştirme çalışması yapılabilsin diye GPL v2 altında kavram kanıtı niteliğinde bir yazılım yaması sağlandı.”
      Bir işletim sisteminin basit bir kavram kanıtı yamasını kabul etmek istememesini anlayabiliyorum.
      Belirli donanım parçalarını destekleyen çok sayıda Linux çekirdeği fork’u var ve bu üzücü. Bu fork’larda çoğu zaman mainline Linux çekirdeğine kabul edilmesi için daha fazla çalışma gereken müdahaleci veya deneysel commit’ler bulunuyor.
      Diğer işletim sistemlerinin burada farklı bir yol izleyip izlemediğini merak ediyorum. Upstream katkılarını kolaylaştırırken mimari, SoC ve kart bakımını yönetilebilir kılmak için ne yapıyorlar?

  • O hâlde denemeyi düşündüğüm zahmetten kurtulmuş oldum. Yine de acı noktalarını belirlemenin uzun vadede yardımcı olmasını umuyorum.

  • Sadece ben zorlanıyorum sanmıştım. Geliştirme sunucusu olarak benzer özelliklerde bir sistem kullandım; sorunların çoğu yerel kod içeren Python bağımlılıklarından kaynaklandı.
    Bazı optimizasyon paketlerini ve Matplotlib’i de hatırlıyorum. Hem normal pip’i hem de uv’yi denedim ama sonunda kaynaktan derlemek zorunda kaldım. Sonunda tamamen x86’ya geri döndüm; açıkçası o kadar çok çekirdeğe rağmen performans da pek etkileyici değildi.

    • “pip ve uv’yi denedim ama sonunda kaynaktan derlemek zorunda kaldım” derken, pip’in dışına çıkıp paketleri elle derlemek zorunda kaldığını mı kastediyorsun merak ettim.

  • Oyun için gerçekten çalışan bir Linux masaüstü istiyorsanız Nvidia kart ve ikili sürücü gerekir; ayrıca Flatpak gibi buna iyi uyum sağlayamayan şeylerden kaçınmalısınız.
    Bu, herhangi bir mimaride onlarca yıldır böyleydi ve bence neredeyse genel bilgi.

    • Ben AMD GPU kullanıyorum ve Linux’ta oyunlar çok iyi çalışıyor. Üstelik eski Nvidia ve o aptal kapalı kaynak sürücü yığınından genel olarak daha az ufak tefek sorun çıkarıyor.
    • Başka işler için Cuda gibi Nvidia’ya özellikle ihtiyacınız yoksa, Linux oyunlarında birkaç yıldır tercih edilen GPU AMD oldu.
    • Ne dediğini anlamıyorum. AMD GPU oyunlarda iyi çalışıyor; örneğin Flatpak içindeki Steam de gayet iyi.
      Steam için Flatpak’te Steam kontrolcüsüne erişim yok, ama bunun dışında sorunsuz çalışıyor.
      Böyle bir iddiada bulunacaksan “bana güven” dışında destekleyici veri de getirmen gerekir.
    • Son birkaç yılda aynı döneme bakınca, AMD tabanlı Steam Deck, AMD APU 5750GE tabanlı mini PC ve Intel Arc B580, NVIDIA 3090’dan pratikte daha iyi bir deneyim sundu.

  • Böyle çekirdek yamalarına hassas bir yapılandırma ise dağıtımın çekirdek paketini hiç kullanmazdım.
    Paket sisteminin dışında çekirdeği kendim derleyip önyükler, sonra kendi hızımda güncellerdim.

  • Bu yazı akışını biraz takip ediyordum; bu kadar uzun süre çalışmış olması bile bana şaşırtıcı geldi.
    Hep “bir şekilde çalıştırma”ya daha yakın görünüyordu; yine de böyle bir sonu okumak üzücü.