[SOS]Multi Threads et Allocation memoire...

[Thomas Petazzoni]

Salut,

On Thu, 17 Nov 2005 11:02:53 +0100
"Romain LABBE" <labbe.romain at wanadoo.fr> wrote:

> Quand je regarde le code de SOS et les flags (ATOMIC) je comprends pas
> ben ou tous ça mène. Je vois pas comment est protégé la vmm
> (sos_disable_IRQs, ou semaphore, ou 
) dans SOS ?

Le flag ATOMIC ici n'a rien à voir avec la synchronisation. Il est
censé avoir la même signification que GFP_ATOMIC sous Linux. Sous
Linux, il y a plusieurs types d'allocations, en particulier GFP_KERNEL
et GFP_ATOMIC. Si il n'y a pas assez de mémoire, alors GFP_KERNEL peut
bloquer, en attendant que le swapper (processus chargé de transférer
une partie des données sur le disque) ou le processus chargé de
synchroniser sur disques les données "sales" du cache de blocs aient
libéré de la mémoire. A contrario, GFP_ATOMIC précise qu'on ne souhaite
pas bloquer, mais qu'on préfère que ça retourne NULL si l'allocation ne
peut être effectuée.

À l'heure actuelle, dans SOS, il n'y a pas de swap, ni de cache des
blocs. Donc finalement, toutes les allocations sont "ATOMIC".

En ce qui concerne la synchronisation, SOS a fait un choix simple: le
noyau n'est pas préemptif. Lorsque du code noyau s'exécute, il peut
être interrompu par une interruption, mais à l'issue de cette
interruption, on retournera _forcément_ dans le thread qui a été
interrompu. Et tant que ce thread n'aura pas effectué une opération
bloquante ou n'aura pas explicitement rendu le processeur, il disposera
de tout le processeur. Cela simplifie grandement l'implémentation,
puisque la synchronisation est beaucoup plus simple: il n'y a souvent
pas besoin de synchronisation, sauf lorsque l'on accède à des données
qui sont partagées avec un gestionnaire d'interruption. C'est dans les
sections accédant à ces données partagées avec les gestionnaires
d'interruption que SOS utilise sos_disable_IRQs(). Pour plus d'infos
sur tout cela, voir section 1.3 de l'article 6.

Pour information, KOS a pris le parti opposé: un OS complètement
préemptif. C'est plus "beau" conceptuellement, mais c'est aussi plus
complexe à implémenter, puisqu'il faut à chaque instant se demander si
une synchronisation n'est pas nécessaire. Et parfois, ce n'est pas
trivial.

Toujours pour l'histoire, le noyau Linux n'était pas préemptif à
l'origine, et jusqu'aux noyaux 2.2/2.4. Lorsqu'un processus effectuait
un appel système, celui-ci s'effectuait d'une seule traite dans le
noyau. Le noyau 2.6 est maintenant totalement préemptif. Il y a
plusieurs raisons à ce changement, parmi lesquelles :
 - un noyau préemptif permet de diminuer la latence de réaction à un
évènement, ce qui est intéressant pour une utilisation "desktop" d'un
ordinateur ;
 - un noyau non-préemptif se comporte assez mal quand le nombre de
processeurs augmente. En effet, dans les anciennes versions de Linux,
quand un processeur était dans le noyau, les autres processeurs ne
pouvaient pas être en même temps dans le noyau, et devaient
attendre... Une perte de performances assez importante, et d'autant
plus importante que le nombre de processeurs augmente.

Voilà. J'espère que cela répond à ta question.

Bonne soirée,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org 
http://{thomas,sos,kos}.enix.org - Jabber: thomas.petazzoni at jabber.dk
http://{agenda,livret}dulibre.org - http://www.toulibre.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://the-doors.enix.org/pipermail/sos/attachments/20051118/1a90fb7c/signature.pgp