Ryzen 9 - ksysguard - CPU freq (diskuse)

[Michal Kubeček]

Chápu, že se chcete o informace podělit, ale IMHO by bylo užitečnější otevřít bug a - protože víte, jak problém (aspoň částečně) řešit - poslat submit request.

[Petr Tomášek]

A to se snad vylučuje?

[Michal Kubeček]

Nevylučuje… ale žádný bug report ani submit request jsem nenašel. Kdyby ano, ten komentář bych nepsal.

[Kate]

Co ten odkaz v druhé větě blogpostu?

[Michal Kubeček]

Mluvil jsem o openSUSE bugzille, když je post o tom, jak si udělat balíček pro openSUSE Leap 15.1.

[Michal Kubeček]

(a stejně tak jsem měl na mysli submit request pro Leap 15.1 - a případně i 15.2, je-li potřeba)

[doron]

Proč jsem to nereportoval v openSUSE bugzille? Jde jen o workaround, až to někdo u ksysguard korektně opraví, bude to opravené i openSUSE.

Chápu, že zkušený uživatel neocení návod jak vytvořit balíček pro openSUSE, ale nelze vyloučit, že to bude číst někdo, komu to přijde vhod.

[Michal Kubeček]

Pokud to měl být návod, jak si udělat upravený balíček pro openSUSE, pak bych spíš doporučil

  osc checkout openSUSE:Leap:15.2:ksysguard5
  # upravit
  osc build

nebo to rovnou udělat v OBS (a pak už je submit request otázkou jednoho příkazu navíc). Distribuční balíčky vesměs moc nepočítají s tím, že by někdo chtěl používat přímo rpmbuild, takže můžete narazit na různé záhadné problémy.

[Michal Kubeček]

Ten první příkaz měl být

  osc checkout openSUSE:Leap:15.1:Update ksysguard5

[doron]

Díky za typ. OBS jsem prozatím nepoužíval. Tak jsem si alespoň zřídil účet, a pokusím se to tam během dne (příštích dní) umístit.

[Nuphar]

Říkal jsem si, že se mi na desktopu s Ryzenem nějak neukazuje frekvence CPU, ale neměl jsem čas to řešit. I takovýto workaround je rozhodně lepší rovnou v OBS, protože výsledek je pak rozhodně přístupnější více lidem a spíš to rozproudí nějakou diskuzi, aby se to pořádně opravilo.

[retroslava]

https://phabricator.kde.org/D27362

[BFU]

Proc se ten soubor read()uje a neudela se na to treba radeji mmap() s PROT_READ ?

[Michal Kubeček]

Protože je to /proc/cpuinfo, kde něco takového nemá šanci fungovat. Správné řešení je nesnažit se odhadnout velikost a načíst celý soubor najednou, ale zpracovávat ho postupně.

[BFU]

No to je teda vysvetleni jak remen, nedik.

Takze jsem si to vygrepoval, ze kernelovy fs/proc/cpuinfo.c + arch-specific kod plni userspacovy buffer pres seq_printf() . Coz by ale zrejme taky znamenalo, ze nejlepsi je to cist po radcich fgets() , jak to dela treba util-linux.

[Michal Kubeček]

Prostě jsem předpokládal, že někomu, kdo používá mmap(), nemusím do detailu vysvětlovat, proč na procfs nepůjde použít.

[BFU]

To jste predpokladal spatne, protoze to, ze jeden soubor v nejakem kernelovem virtualnim FS neimplementuje .mmap neznamena, ze jiny soubor - klidne ve stejnem virtualnim FS - ten .mmap neimplementuje taky. Ono by vesmes stacilo ten mmap do fs/proc/cpuinfo.c pridat, struct file_operations {} ma callbacky na vsechno mozne, ale ten duvod proc to tam neni jsem popsal vyse.

[Michal Kubeček]

No tak se zkuste podívat, kolik těch proc_mmap celkem v jádře existuje. Já tam vidím celé čtyři kusy - z toho tři jsou věci, které mají k něčemu jako /proc/cpuinfo zatraceně daleko a jeden navíc existuje jen na powerpc.

[BFU]

To ja nevim, rychly git grep tvrdi neco pres 500:

linux-2.6$ git describe HEAD

next-20200316

linux-2.6$ git grep '[[:space:]]\.mmap[[:space:]]*=' | wc -l

516

Cely ten proc_* je wrapper okolo genericke implementace virtualniho FS v Linuxu, nad kterou je postaveny i sysfs, debugfs, configfs atd.

[Michal Kubeček]

To jste si ale vymyslel úplně jinou otázku, než na jakou jsem se ptal.

Zkuste se nad tím trochu zamyslet. Ten soubor vzniká on demand a dopředu nezjistíte ani jeho velikost (dostanete nulu). Jak ho chcete mmapovat? Co tomu mmap() předáte jako velikost?

[BFU]

Viz vyse muj komentar o seq_printf().