[SOS]Multi Threads et Allocation memoire...

[Romain LABBE]

Salut Thomas,

Cela repond en partie à ma question, mais du coup il faut donc bien
protéger l'allocateur de memoire virtuelle.
Par exemple dans Linux 2.6 pour protéger le kVmm on utilise quoi ? Un
semaphore ? On désative les interruptions lors de l'allocation ? Autre ?

Merci

A++

Romain



> -----Message d'origine-----
> De : sos-bounces at the-doors.enix.org 
> [mailto:sos-bounces at the-doors.enix.org] De la part de Thomas Petazzoni
> Envoyé : vendredi 18 novembre 2005 00:03
> À : sos at the-doors.enix.org
> Objet : Re: [SOS]Multi Threads et Allocation memoire...
> 
> 
> 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
>