Názory k článku
Jádro bude mít -march=native

Hmm, toto vyzerá čudne. Nebolo by lepšie kompilátoru rovno podhodiť konfigurák s konkrétnymi vlastnosťami procesora?

Kebyže kompilujem custom kernel na viac ako 3 dostatočne rozdielne typy procesorov naraz, usiľoval by som sa to nejak prechytračiť.

Tak nejlepší je kompilovat 3x. Ale pokud byste chtěl, tak stačí kouknout, co to -march=native zapne na jednotlivých strojích, najít nějakou podmnožinu a to pak použít.

gcc -march=native -Q --help=target
KCFLAGS="-O3 -march=xxx -mno-sse -mno-mmx ..."  make -j$(nproc)

Skôr asi by som to kompiloval 3x, ale na najrýchlejšiej mašine. Ak sa dá pozrieť, čo -march=native zapne, tak to nie je problém.

Ďakujem :)

Tak prosté a doteď to nebylo. Neuvěřitelné. Kompilátor samozřejmě vycházel z nějakých systémových settings, kde byla naspecifikovaná platforma.
Ale nevidím důvod, proč by si kompilátor nemohl tento údaj získat třeba ze systemd nebo nějaké utility, která vrací hodnotu architektury (ala uname), tím se vše zase o něco zjednodušší a stane elegantnějším.

To nastaveni nebylo systemove od prekladace, ale skrze KConfig ... viz:

arch/x86/Kcon­fig.cpu
https://elixir.bootlin.com/linux/v6.12.4/source/arch/x86/Kconfig.cpu

v menuconfig pod:

Processor type and features  --->
Processor family (Generic-x86-64)  --->

Generic je něco jiného, to má jet na všech x86_64.

to Generic je nastaveni z konkretni instance odkud jsem to vykopiroval

Pokud vlezete do toho nastaveni, tak mate na vyber nekolik moznosti, ale ani jedna neni "native". Nove se tam prida tahle volba.

Ja rozporoval predchozi komentar, ze se -march bere z beziciho systemu - ne, nebere. Bere se z nastaveni zdrojaku a nastaveni (.config) jadra, kdyz si ho kompilujete sam.

Konkretne krome genericke -march, je tam na vyber pouze tohle:

cflags-$(CONFIG_MK8)            += -march=k8
cflags-$(CONFIG_MPSC)           += -march=nocona
cflags-$(CONFIG_MCORE2)         += -march=core2
cflags-$(CONFIG_MATOM)          += -march=atom

tak nebylo, uz delsi dobu kompiluju kernel stylem make "KCFLAGS=-march=native -mtune=native". ale pokud to bude primo volba, tim lepe.

A proboha, to s tim systemd-mezikusem mezi /proc/cpuinfo a kompilerem radsi nikde nerikejte nahlas, nebo se toho jeste nekdo chytne :-(.

Hele já jsem pro, proč číst /proc/cpuinto, když by to mohlo mít třeba dbus interface? /s

15. 12. 2024, 10:16 editováno autorem komentáře

Pokud jde o strukturovaná data (aby to nebyl jeden velký texťák s hromadou hodnot v lidsky čitelném jazyce nebo nějakém nespecifikovaném pseudo-formátu), tak to jde i v těch syntetických souborových systémech (/proc, /sys, ...). V souboru máš jednu konkrétní hodnotu a těch virtuálních souborů a složek je tam víc a je to hezky strukturované. Resp. ne jen že to jde, ale je to běžný standard.

D-Bus je k tomuhle trochu duplicitní technologie. Resp. je to spíš věc podobná SNMP nebo JMX. Ostatně to „D“ v názvu znamená „Desktop“. Daleko větší smysl to dává třeba v případě, že multimediální přehrávač chce vystavit svoje API (a ty pak můžeš zapnout/vypnout přehrávání i jinudy než přes GUI toho přehrávače). D-Bus má svoje kouzlo a využití, ale pro zjišťování informací o procesoru by to neměla být primární natož jediná cesta.

OK, tak ja to /s udelam jeste priste tucne :)

nemyslel jste spis dmidecode vs /proc/cpuinfo ?

Co máte s tím /proc/cpuinfo? Vždyť stačí pár CPUID instrukcí a člověk ví všechno aniž by musel číst /proc. A toto má dnes už i AArch64.

Treba ze je to multiplatformni a nemusim se trapit assemblerem na obskurnich platformach. Linux fakt neni jen x86 a arm. Plus ta informace muze byt zmenena vuci tomu co rika hw - treba v pripade vadneho hw, nebo hw ktery neco nechce priznat, ale funguje to. To fakt nechci resit rucne podle nejakych errata.