[SOS] Allocation Memoire Physique & Macro (List.h)

[romain]

Salut,


Question 1:
-----------

b = (a > 2) ? 1 : 0;
Ok on peut donc écrire cette sorte de syntaxe alors:  condition ? Retour
si vérifié : Retour si non-vérifié;
Merci c'est l'impide désormais !

If ( List ) return List->Prev else return NULL;

Merci pour cette clarification !

Question 2:
-----------

Ok c'est une "Convention" local à SOS du coup !
C'est vrai cette logique est sympa:

-Les pages plus neuves ou dernierement libérées en début de queue libre
-Les pages dernieremet alouées en  fin queue utilisé

Du coup avec cette methode on augmente les probabilités d'allouée les
pages proches du noyau.
Comme on initialise les descripteurs de pages dans l'ordre d'adressage
de ses pages, je me dit que si on aloue les premieres descripteurs plus
souvent donc on alloue les premieres page plus souvent. 
(J'ai dans l'idée que les pages les plus utilisées seront en theorie les
premieres pages)
Est-ce que je dit des bêtises ou pas ?


Merci pour toutes ces infos

Bon courage et Bonne journée

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é : jeudi 20 octobre 2005 13:49
> À : SOS mailing-list
> Objet : Re: [SOS] Allocation Memoire Physique & Macro (List.h)
> 
> 
> Salut,
> 
> romain wrote:
> > Salut,
> > 
> > Ca fait un moment que je n'interviens pas, mais je lis les messages 
> > tres régulierement, en ce moment c'est assez tranquille sur la news 
> > donc j'en profite pour poser des questions comme qui dirait basic:
> > 
> > En fait je me casse la tete sur l'allocation memoire, je suis donc 
> > repartis depuis l'Article 3. Je suis pas tres alaise avec 
> les Macros, 
> > j'ai mis du temps à piger le principe de "Named" dan le 
> fichier List.h 
> > qui ne contient que des macro (un casse tête pour moi). Disont 
> > qu'apres avoir compris le principe des macro "Named" je me 
> suis dit !
> > 
> > "Purée c bien en fait les macros !"
> > (j'y etait un temps soit peut récalsitrant)
> > 
> > Question 1:
> > -----------
> > Dans un premier temps j'aimerais que l'on m'explique une bonne fois 
> > pour toute le fonctionnement (syntaxique) de ce genre de macro: ( 
> > list_get_tail_named )
> > 
> > ((list)?((list)->prev):NULL)
> > 
> > Je l'ai rencontré assez souvent, j'imagine que c'est un test, 
> > (simplifié en macro), j'imagine aussi que derriere les : c'est les 
> > paramtres de retour mais si j'essaye de comprendre j'en arrive a ça:
> > 
> > Si list est égale a list->Prev alors le define équivaut à 
> mettre NULL, 
> > quand je regarde le reste du source et le nom "Récupere la 
> queue" et 
> > que la liste est circulaire j'imagine qu'elle retoure 
> Head->Prev qui 
> > est bien la queue (la fin).
> > 
> > Mais dans la syntaxe c'est pas explicite ! J'ai un doute sur le 
> > fonctionement du coup !
> > 
> > Quelqu'un peu t il m'éclaircire les idées sur le genre de 
> syntaxe avec 
> > des '?' et des ':' ?
> 
> Ok. Reprenons ton exemple. L'expression 
> '((list)?((list)->prev):NULL)' vaut list->prev si list est 
> vrai, sinon l'expression vaut NULL.
> 
> Un exemple plus simple:
> 
>  b = (a > 2) ? 1 : 0;
> 
> b vaudra 1 si (a > 2) est vrai, sinon b vaudra 0.
> 
> Dans l'expression de départ, le test est simplement "(list)", 
> ce qui veut dire (list != 0), donc (list != NULL).
> 
> > Bref tous ca pour dire que je comprend pas pourquoi on 
> ajout en "Tête" 
> > ou en "Queue" de la liste circulaire ! Quel est l'intérêt ?
> 
> Il faudrait que je regarde en détail le code, mais il me 
> semble qu'il n'y a pas de raison particulières qui poussent à 
> insérer en queue de la liste des pages utilisées et en tête 
> des pages libres. Je crois que c'est parce que ça nous semble 
> "logique" d'insérer les pages nouvellement utilisées en queue 
> de la liste (ainsi les pages les plus anciennes sont au 
> début, les pages les plus neuves sont à la fin). Et d'insérer 
> les pages libérées en tête, pour que ce soit ces pages qui 
> soient réallouées ensuite.
> 
> Néanmoins, faudrait que je vérifie tout ça, à moins que David 
> ne confirme/infirme.
> 
> > Edouard j'etait comme toi partisant du modele sans pagination, ( en 
> > fait j'etait comme toi partisant d'un allocateur de memoire 
> simple :P 
> > ). j'ai fait mes recherche mais je doit me rendre à 
> l'évidence que de 
> > ne pas utiliser la pagination rend les choses encore plus compliqué 
> > (plus c'est possible ? (' ) ( .) ) bref, j'y etait 
> récalsitrant mais 
> > je suis bien forcé de m'y mettre. Si tu trouve une solution, pense 
> > quand meme à la news ;).
> 
> Je ne pense pas que ce soit impossible, mais simplement les 
> outils (notamment le compilo) pré-suppose un modèle de 
> gestion mémoire "à plat", sans segmentation. D'autre part, 
> une fois qu'on a commencé à raisonner en termes de système 
> utilisant la pagination, je trouve qu'il est difficile de 
> réfléchir à comment ça pourrait marcher sans.
> 
> Bonne journée,
> 
> Thomas
> -- 
> Thomas Petazzoni
> thomas.petazzoni at enix.org
> 
> _______________________________________________
> Sos mailing list
> Sos at the-doors.enix.org 
> http://the-doors.enix.org/cgi-> bin/mailman/listinfo/sos
>