Názory k článku
Jádro 6.17 bude i pro jednojádrové procesory používat SMP

Ten titulek mi přijde zavádějící, byť aspoň ve druhém odstavci to bylo vysvětleno.

Titulek byl příliš málo informativní, snad je to teď po změně lepší.

Super, mnohem lepší!

Nedělali jste někdo testy s nějakým recent kernelem?

Kdysi hodně dávno jsem to dělal (už si nepamatuju, kolem trojky), a vycházelo mi, že ten rozdíl byl dost velký (vyšší desítky ns versus vyšší stovky ns na syscall). Pravda pro běžnou zátěž celkem zanedbatelné, většina neběžné používá dnes nějaký ten io uring apod., ale pár use cases by se asi pořád našlo.

Všetečná otázka: kolik z těch, kdo takovou neběžnou zátěž provozují a pro něž je výkon kritický, ji dnes provozují na jednojádrových procesorech? A pokud běží na vícejádrovém, bylo by potřeba porovnat, jestli ta režie SMP jádra nebude vyvážena tím, že se příslušná úloha nebude muset o procesor dělit s ničím jiným (pokud se využije CPU isolation).

Pokud se Linux pouziva namisto zavadece, je rychlejsi SMP vypnout, protoze zavadeni operacniho systemu nejde moc paralelizovat a bootovat sekundarni CPU a pak je zase vypinat si nejaky cas ukousne a zaroven i znacne zvetsi jadro, ktere krome plne implementace spinloku musi obsahovat i kod pro CPU hotplug. Toto dohromady muze prodlouzit boot klidne i o 2s.

Ty dvě sekundy jsou reálně naměřená hodnota nebo jen nějaký odhad? A pokud naměřená hodnota, tak (1) dvě sekundy z kolika a (2) je to typická hodnota nebo pečlivě vykonstruovaný corner case?

Namerena hodnota na jadre 5.15, na kterem byl zalozen zavadec, ktery jsem vyvinul pro zakaznika. Celkova doba bootu se touto optimalizaci zkratila asi o 5,4%. Doba bootu je kriticka, protoze rychlejsi boot dovoli casteji restartovat system pri zachovani stejne dostupnosti.

Salamova metoda paradoxu v praxi.

Vyhodime podporu starych cpu, protoze nemaj atomicke operace nutne pro synchronizaci SMP, ale tyto cpu v SMP stejne nejeli.

Zapneme SMP pro neexistujici 1C procesory, ktere uz stejne nepodporujeme.

Myslim ze Linux potrebuje konkurenci jako sul, ta dominance zacina mit negativni efekty a priblizuje se k ne-nabidce a nuceni podobnych z komercnich reseni.

Muzete s ni prece prijit. A stavet muzete klidne na tom legacy kodu, ktery je vyhazovan... v gitu porad k nalezeni prece je :-)

Upřímně teď se úplně nechytám, ale zas nesleduji ty embedded a okrajové platformy tak detailně.
Které procesory se vyházely, protože SMP? Zaznamenal jsem, že se třeba čistily přímo nějaké vendor specific architektury, např. MIPS/TI AR7, ale tam si myslím, že to bylo hlavně kvůli neudržovaným platform driverům bez maintainera a testování.

Neexistující 1C procesory, co nepodporujeme - taky teď nevím, určitě jsou pořád mezi lidmi minimálně nějaké Atomy, MIPSy, Broadcomy v první generaci RPi Zero atp. Pojedou normálně se SMP jádry (víceméně stejně jako do teď, pokud jsou tam standardní distribuce). I nějaké opravdu historická 1C CPU jako Motoroly z řady 68k jsou podporované.

Plus ty důvody v originálním patchsetu mi přijdou vcelku rozumné:
https://lore.kernel.org/lkml/20250528080924.2273858-1-mingo@kernel.org/

Myslim ze Linux potrebuje konkurenci jako sul, ta dominance zacina mit negativni efekty a priblizuje se k ne-nabidce a nuceni podobnych z komercnich reseni.

Jakože by se teď někdo pustil do vývoje konkurenčního systému, můžeme mu říkat třeba RetrOS, s nekonečnou délkou podpory všech zařízení a architektur, kde systém běžel a které už vlastní výrobci dávno zazdili..?

Jedna věc je sentiment, druhá asi pak nějaká realita vývoje u takhle velkého projektu jako je Linux.
A jinak podle mě daleko větší problémy s omezenou praktickou životností jdou na vrub některým výrobcům, kteří si udělají podporu na čip/SoC v nějakém svém vendor forku s out-of-tree ovladači a ani se moc nesnaží to rozumně dostat do mainline jádra.

víceméně stejně jako do teď, pokud jsou tam standardní distribuce

Běžné distribuce speciální UP jádro přestaly nabízet už dávno, takže tam to poběží přesně stejně jako doteď. To, že byla možnost takové jádro přeložit, neznamená, že se v distribučních jádrech také využívala. Což je ostatně součást problému: reálné využití, a tedy i míra praktické testovanosti takových konfigurací byly čím dál slabší.

Taky jsem chvíli pátral v paměti, jestli jsem se s UP jádrem někdy v poslední době setkal. Ale opravdu spíš ne. Na běžných distribucích vůbec a i na tom zmíněném RPi Zero je unifikované SMP jádro z Debianu pro 32bit ARM.
Možná tedy starší Mikrotiky s MIPSBE architekturou měly 1C SoC, v RouterOS na tuhle platformu je teď pořád relativně starší jádro 5.6.3. Nebo ještě některé specifické cílové platformy v OpenWRT mají teď UP buildy (další verze jádra bude LTS 6.12), což ale samozřejmě neznamená, že by to s 6.17 a dál v SMP režimu nutně nemělo běžet. A byť se tam šetří místem, tak pokud se jedná o zvětšení velikosti image v řádu desetin procenta, asi by to nemělo působit problémy.