OpenMosix Minipaper 0.2 per il LinuxDay 2002: v0.2

[alexmaz]

Io l'ho letto, mi sembra buono... l'unico punto che mi convince poco, ma non per colpa tua, è quello sull'implementazione dei thread... per definizione, credo, i thread di uno stesso processo devono condividere lo stesso spazio di indirizzamento (per "operare" sugli stessi dati) quindi anche i thread su altri OS avrebbero gli stessi problemi di migrazione che su linux. Questa almeno è una mia impressione, da verificare

ciao

[rejected]

Ciao Alexmaz. Grazie per il suggerimento.
In effetti ciò che dici è giusto. I thread per definizione (quindi su qualunque SO "standard" che supporti i thread) condividono tanto lo spazio di indirizzamento quanto altre risorse (process descriptor incluso).

Ma, se i thread fossero...
- indipendenti "logicamente" fra loro (ognuno fa il suo lavoro senza curarsi degli altri).
- magari la libreria dei thread fosse in user-space (le librerie in kernel-space sono troppo legate al sistema ospitante)
...allora Mosix, IMHO, potrebbe sganciarli e riattaccarli sui vari nodi.

In ogni modo la futura cluster-shared-memory dovrebbe risolvere il problema a monte.

Intanto grazie per la segnalazione: ne terrò conto.

Grazie.

<JP>

[alexmaz]

Si infatti parlavo di thread a livello kernel... per quelli in user-space in effetti non dovrebbero esserci problemi (sempre a seconda dell'implementazione) ma secondo me non sono una gran soluzione (non in questo caso a livello di test, ma in generale) in quanto l'OS in se (il kernel) non è a conoscenza dell'esistenza di + thread all'interno di un processo e questo ha le sue noiose conseguenze...

ciao

[rejected]

Ragionamento corretto il tuo, Alexmaz.

Infatti i thread totalmente in user-space sono invisibili al kernel e ci vuole qualcos'altro che li gestisca (altre librerie => nuove sovrastrutture => probabile decremento delle prestazioni).

Se però pensi che esiste più di una versione del kernel Linux in user-space ciò signifca che qualcuno probabilmente ha già creato queste sovrastrutture...

Byez.

<rejected>

[alexmaz]

Ho mandato il form per il convegno, se riesco vengo...

[rejected]

Allora magari ci si vede...

Fammi sapere che magari ci organizziamo per trovarci al Cineca...

<rejected>

[alexmaz]

Io cerco di venire... e se vengo cerco di venire in macchina che mi è più comodo...

Ho installato openMosix su 3 pc a casa (che fatica usare + distribuzioni, bisogna ricordarsi troppo roba ) ...

figata:

uno dei nodi è un Pentium Pro 200... mi sono collegato in ssh e ho notato che rispondeva meglio... guardo e... sshd è migrato sull'Athlon XP

fantastico

[alexmaz]

è velocissimo nel migrare i processi!!! ho lanciato il mio complesso test stressa cpu

main(){
      for( ;; );
}

e dal Pentium Pro e schizzato subito sull'Athlon...

[rejected]

Il programmino migra perchè
- Occupa la CPU al 100%
- Occupa pochissima Ram, ma le risorse (memoria esclusa) coinvolte sono enormi
- Openmosix vede che il programma non fa altro che consumare tempo di CPU (senza operare su variabili condivise,...) e quindi il relativo processo è migrabile.

Nota che le varie instanze dle programmino sono processi (creati dalla shell tramite fork()/exec()) e non thread e, di fatto, sono tranquillamente migrabili.

Prova il mio programmino che usa i PThread (ptDiv):
http://filibusta.crema.unimi.it/mosi..._minipaper.htm
(sezione: PThread e OpenMosix (WIP)"): vedrai che non migra... (a me non migra).

Poi leggi sotto (a quella sezione), perchè non va...

>> Anzi, se lo provi e mi dici se è successo qualcosa, mi fai un grosso piacere. (In questo momento sto ricostruendo il cluster e non posso utilizzarlo!) <<

Grazie...

<rejected>

[alexmaz]

Non migra...

secondo me questo semplice esempio rispecchia un problema nell'implementazione di thread e processi di linux, che era gia venuto fuori in una discussione qui qualche tempo fa...

capisco il problema di migrare un singolo thread di un processo, ma se io volessi migrare tutto il processo non si sarebbero problemi... ma con linux non posso! Qual'è il pid del processo? se dai un ps aux vedi che vengono elencati tutti i thread creati con pid diversi e questo è semanticamente sbagliato. O meglio, in linux non esistono entità processi o thread, ma diciamo dei task che possono condividere o meno lo spazio di indirizzamento e altre risorse. Questo secondo me è un limite, soprattutto per applicazioni di questo tipo.

[alexmaz]

Infatti...

The Linux POSIX thread implementation is using individual processes for each thread. These are not completely separated processes but instead since they have to shared things like virtual memory, file descriptors and the like.

However, the kernel does not really know the difference between threads and processes. Therefore it does not handle the delivery signals correctly. There is no single process ID (each thread has its own, which is another difference from the POSIX standard) and the kernel is delivering the signal to that thread.

[rejected]

Tratto da:
http://pauillac.inria.fr/~xleroy/lin...ads/faq.html#K

"K. Internals of LinuxThreads
K.1: What is the implementation model for LinuxThreads?
LinuxThreads follows the so-called "one-to-one" model: each thread is

actually a separate process in the kernel. The kernel scheduler takes care of

scheduling the threads, just like it schedules regular processes. The threads

are created with the Linux clone() system call, which is a generalization of

fork() allowing the new process to share the memory space, file descriptors,

and signal handlers of the parent.

Advantages of the "one-to-one" model include:

* minimal overhead on CPU-intensive multiprocessing (with about one

thread per processor);
* minimal overhead on I/O operations;
* a simple and robust implementation (the kernel scheduler does most of the

hard work for us).

The main disadvantage is more expensive context switches on mutex and

condition operations, which must go through the kernel. This is mitigated by

the fact that context switches in the Linux kernel are pretty efficient."


Devo correggere un po' di cose...


<rejected>

[alexmaz]

Il problema è che proprio il concetto di processo non esiste o quasi... anche Windows 2000 fa lo scheduling dei thread e non dei processi, ma il pid è assegnato per processo, non per thread...

[rejected]

Hai ragione, ma ci sono alcune differenze...

Windows e Linux (stando a quello che emerge leggendo il nuovo Tanenbaum) sono due entià distinte anche se entrambi muovono thread e non processi (come fa invece lo UNIX standard).

In Windows ci sono 4 tipi diversi di contesti di esecuzione:
- Job
- Process
- Thread
- Fiber
E come giustamente hai detto tu, il thread è il vero "context of execution" e il process è il contenitore (e ha il PID). Il kernel schedula quindi i thread.


In Linux abbiamo soltanto processi e thread. Anche in questo caso lo scheduler muove solamente la parte in kernel-space e quindi solo i "thread kernel, e per questo, lo scheduling è sempre basato sui thread e mai sui processi" (Tanenbaum).

D'accordo con te che non ci sia una differenza enorme fra thread e process in Linux, ma ognuno di essi ha un suo PID univoco (il processo padre deve pur sapere come chiamare i suoi figli).

Se lanci ptDiv vedrai che ogni thread ha il suo PID (guarda top e/o ps aux).
(http://www.oreilly.com/catalog/linux...pter/ch10.html)

Ovvio che killando un thread, provochi la morte di altri thread e, probabilmente, anche del process parent.

Che ne pensi?

<rejected>

[alexmaz]

Si si, ma il problema sta proprio nel fatto che non c'è un pid per il processo, ma solo i pid dei thread... se io mi volessi riferire al processo, che pid prendo?

In sostanza il processo per il kernel non esiste, esistono solo dei thread con lo stesso spazio di indirizzamento e stessi descrittori dei file... è la stessa cosa, però...

[rejected]

Leggendo la FAQ ufficiali dei LinuxThreads (i thread in kernel-space interni a Linux),
si legge che "The kernel scheduler takes care of scheduling the threads, just like it schedules regular processes. ".

La citazione è tratta dalla sezione "K. Internals of LinuxThreads".


Ora, siccome Tanenbaum parla dei thread del kernel 2.2 e queste FAQ sono quelle ufficiali scritte dagli autori dei thread di Linux serie 2.4, direi che do la palma del vincitore agli autori della FAQ.

Quindi posso dire che Linux, muove thread e processi e non solo thread come Windows2000/XP...

O sbaglio?

PS: ora voglio vedere cosa cambierà con la serie 2.6...

<rejected>

[rejected]

Prendi un processo monothread.
Ogni processo di questo tipo ha un (solo) main-thread in kernel-space. Il PID è quindi assegnato al main-thread e quindi,di riflesso, al processo.

Anche nel caso di processi a thraed multipli esiste cmq un main-thread per caiscuno (quello col PID più basso, perchè è il primo ad originarsi). Di fatto esiste quindi un PID per il mainthread-processo e n PID per i thread che si dipartono da esso (che sono anch'essi in kernl-space).

Che dici?

<rejected>

[alexmaz]

No secondo me lo scheduler muove solo i thread, non ha possibilità di muobere i processi...

si c'è sicuramente un thread "principale" o di controllo... cmq tutti i thread in linux sono visti a livello kernel, questo è sicuro

[flisi71]

Sono appena rientrato e passo qui di sfuggita proprio per leggere gli ultimi sviluppi, e chi ci trovo? il nostro amico Alexmaz!!!

Bene, benissimo.

Ora devo finire di sistemare alcune cose ma lunedì mi leggo tutto e provo a postare qualcosa di utile!!!!

Ciao!!!

P.S. Grazie della tua premura di tenermi informato!!!


Federico

[rejected]

Ciao Flisi. Passate bene le vacanze?

---- O ----

Alexmaz, ora spiego bene cosa intendevo col post intitolato "PID".

Il kernel muove solo parti in kernel-space quindi muove solo i thread.

Siccome i processi hanno una parte in kernel space (il main-thread) ed una parte in user-space sembra che anche i processi siano schedulati mentre nella realtà sono schedulati _solo_> i suoi thread in kernel-space(il main e quelli che si dipartono da esso, come i PThread).

Di fatto la definizione di Tanenbaum è la più corretta (Linux schedula solo i thread).

Ma sebbene la cosa risulti fuorviante, anche la definizione trovata sulle FAQ dei LinuxThreads non è errata "logicamente": di fatto il processo è/ha un thread a sua volta e quindi potremmo dire che viene schedulato anche lui (perchè lo è il suo main-thread!).

E' solo un equivoco a livello lessicale/logico.

In ogni caso (ribadisco): Linux muove solo thread, non processi!

Va bene, come spiegazione?

<rejected>