Řeší Linux afinitu procesů a vláken jinak?

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Rád bych se přiučil a zjistil něco o přiřazování afinity procesů (a threadů) v Linuxu. Zkoušel jsem to a trochu mě to překvapilo. Jediné, co vím, že systém procesů a vláken oproti windows je "jiný". (tipl bych zjednodušeně řečeno plochý v linuxu, ve Windows hiearchický)

Spustil jsem si gnome mapy. To je spuštění procesu  id . 4142

Přehodil jsem mu afinitu pres taskset -p -c 3 4142. Ale vidím, že ostatní jádra jsou stále zatížená.
pidof gjs stále hlásí 4142.


Ale když si v htop "rozkliknu myš a Thready", vidím víc gjs 4143,...,atd
ale /proc/4143  je skoro samé jako 4142

Musím proto i dát taskset -p -c 4143

Jak to v kostce funguje?
-kde najdu referenci v procfs /proc/4142 na detičný thread 4143 ? Našel jsem /proc/nn/task, le to je seznam threadů a jak z něj zjisím hlavní thread. (Pochopil jsem, že PID A TID se nerozlišují a hlavní vlákno  má TID jako PID v podstatě -- htop rozlišuje zeleně vlákna od černě procesů)
- proč  kill 4143 (zabití threadu). Zabije celou aplikaci ?(Laicky nepoznám, jestli příkaz KILL $TID  sám o sobě zabije prices patřící danému threadu, nebo crash threadu probublá nějak v aplikaci a ta se sama ukončí) Jak zabít vlákno? Ve windows to umí Process explorer- proces -dvojklik- tab Threads a mám jejich seznam včetně TID.

-Jde to jednodušeji než for i in /proc/$(pidof gjs)/task/ ; do  taskset -c -p 1,2,3 $i ; done?
-Prostě abych nemusel se zobírat, že aplikace má nějaká vlákna, když pomocí taskset chci přiděli afinitu procesu - a ten proces má v případě složitější aplikace víc vláken

[Reklama]

[RDa]

Bylo by dobre si zopakovat zaklady OS a co znamena mit vicevlaknovou aplikaci.

Vlakna jsou jednoduse taky procesy, ktere pak sdileji s hlavnim procesem stejnou pamet (z pohledu aplikace).

kill PID zabije jen proces vlakna, ale aplikace ti pak nejspise spadne
kill -PID zabije celou skupinu procesu

Jelikoz je vse OSS, tak si to spust v debuggeru a uvidis co se deje.

[FactChecker]

Také by bylo dobré, naučit se používat man. Pak bys odhalil, že taskset má volbu -a.

[František Ryšánek]

https://stackoverflow.com/questions/58370707/what-is-the-thread-group-leader-name-in-the-proc-file-system
Ty cesty v procfs jsou popsány v prvním komentáři.

Kernel provozuje v zásadě vlákna / threads. "Aby se to nepletlo", tak klíčový kernelový objekt, který drží informaci o jednom konkrétním vlákně, např. má atribut thread_id, se jmenuje "struct task_struct" :-(
https://chengyihe.wordpress.com/2015/12/29/kernel-thread-and-thread-group/

User-space process pasuje na kernelovou "thread group", z toho jedno vlákno je "thread group leader" = jeho TID figuruje též jako PID za celou skupinu, jinak ale thread group leader nemá žádné výsadní postavení. Je to prostě první vlákno programu, kterým začalo provádění programu (procesu). Pokud mohu soudit, "thread group" nemá žádný svůj objekt (struct), který by se instancioval - pouze thread group leader ve svém "struct task_struct" obsahuje pointer
struct task_struct *group_leader;
...plus dva list-heady pro dětičky a sourozence.

Takhle to figuruje v kernelu. User space (libpthread resp. NPTL v rámci libc) nad tím pentlí nějaké svoje mírně odlišné názvosloví.

A závěrem kvízová otázka pro chtré hlavičky, jestli dávaly pozor: co je to "struct task_group" ? Inu není to objekt pro "thread group" nebo-li kernelový pohled na rozvlákněný proces. Je to struct pro "control group" = skupinu procesů, která patří přihlášené terminálové relaci...

Připadá to někomu srozumitelné? :-D

Ve starší linuxové implementaci phtreadů (linux-threads, v linuxu 2.4) volání getpid() vracelo v každém vlákně jiný PID, tzn. ID vlákna. Tentýž kód zkompilovaný pro Linux 2.6/NPTL vracel ve všech vláknech tentýž PID. Takže když jsem chtěl držet seznam vláken podle jejich vlastních ID, pídil jsem se, kde ho vezmu - a ejhle, během nějaké doby probublal do user-space hlavičkového souboru s kernelovými syscally nový syscall gettid(). Dále pthread_create() od téhož okamžiku už nevrací PID, ale pointer na struct... (toto se skrývá pod typedefem pthread_t).

viz též man getpid, man gettid

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Díky moc za info a odkazy. Použil jsem jen man pidof, ne man taskset 

[Reklama]