[SOS] article 5: ajout

[Thomas Petazzoni]

Salut,

anthoine.bourgeois a écrit :

> Dans les constructeurs, on dois mettre tout les initialisations et
> dans les destructeurs on fait uniquement des assertions pour vérifier
> que l'objet est dans un état cohérent. L'avantage c'est que, au lieu
> de faire ça à chaque fois que on alloue un objet et le désalloue, on
> ne le fait qu'une fois pour toute à la création du slab et à ça
> destruction cela quelques soit le nombre d'allocation du même buffer.
> On déporte donc les initialisations obligatoires, des mutex,
> compteurs de référence ou toutes autres choses qui à besoin d'être
> initialisé, dans le cache. Il faut bien évidement créé son cache pour
> un seul type d'objet dans ce cas là, ça ne fonctionne pas avec les
> objets générique de kmalloc.

Oui, le principe, je le connais. Ce que je mets en doute, c'est son
utilité pratique: la plupart du temps, ces initialisations obligatoires,
c'est trop fois rien (un memset, deux trois variables, peut-être un
sémaphore), bref, rien de bien violent.

Et vu que c'est trois fois rien, je me demandais si le jeu en valait la
chandelles finalement, puisque le maintien de la free_list (en dehors du
slab, ou dans le slab en agrandissant les objets) mange quand même pas
mal de mémoire, surtout pour des tailles d'objets petites.

> Je n'ai pas trouvé de cas vraiment intéressant dans SOS mais il y en
> a peut être ou il y en aura sûrement. Je pense au structure des
> threads, processus, inodes...

Ouaip, il faudrait regarder, mais encore une fois, j'ai l'impression que
dans la majorité des cas, y'a vraiment trop fois rien pour
l'initialisation elle-même.

En plus, ça t'oblige à rendre l'objet dans un état propre, sinon le
projet qui va l'allouer (et considéré que ça été initialisé une bonne
fois pour toute par le constructeur) va se manger les pieds dans le tapis.

> Les ctors/dtors ne consomme pas beaucoup de mémoire simplement 2
> pointeurs de fonction par structure de cache.

Je ne parlais pas des ctor/dtor eux-mêmes, mais bien du maintien de la
liste des objets libres sans utiliser l'espace mémoire de ces objets. Et
c'est à cause des ctor/dtor qu'il faut faire cela.

> Tout mesuré sous bochs. J'ai d'abord implémenté les free_list et j'ai
> obtenu un gain de 5-6% Pas franchement folichon. Je ne m'attendais
> pas à une telle évolution avec le cache coloring.

J'ai pas beaucoup réfléchi, mais je comprends pas comment les free_list
seules peuvent améliorer les performances. Tu peux m'en dire plus ?

> C'est dans le papier de Bonwick. Il conseil une trentaine de cache de
> 8B à 9KB qui croissent de 10 à 20%

Ok.

> C'est exactement ça. C'est pas la chose la plus propre que j'ai fait
> je reconnais.

Pas de problème, le code est vraiment très lisible !

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
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: 256 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/sos/attachments/20050927/2fd5f260/signature.pgp