[SOS] article 5: ajout

[Sebastien BERIDOT]

J'ai relu les mails de ce soir, et j'avoue ne pas y avoir trouvé la 
référence à cet article de Jeff. L'article auquel tu fais référence 
serait-il donc celui-çi?
http://srl.cs.jhu.edu/courses/600.418/SlabAllocator.pdf
S'il était possible de le préciser à l'avenir! :)
Et si cela a été fait, ben pardonnez moi alors.
Sincerement, et au plaisir de vous lire
Sebastien

anthoine.bourgeois a écrit :

>Bonsoir,
>
>  
>
>>>- les constructeurs et destructeurs
>>>      
>>>
>>Lorsque j'avais implémenté le premier allocateur par slab de KOS,
>>j'avais étudié le papier de Bonwick, et son histoire de
>>constructeur/destructeur. Sur le papier, ça m'avait paru séduisant, mais
>>quand je voyais en pratique comment on utilisait les slabs dans KOS,
>>j'avais l'impression qu'on ne pourrait finalement pas mettre grand chose
>>dans ces ctor/dtor, à part un memset() à zéro et quelques
>>initialisations de champs.
>>    
>>
>
>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.
>
>  
>
>>Par curiosité, est-ce que dans le cas de SOS, tu as trouvé des cas où
>>l'utilisation de constructeurs/destructeurs était vraiment intéressante?
>>    
>>
>
>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...
>
>  
>
>>J'ai l'impression qu'on gagne finalement assez peu avec ces
>>constructeurs/destructeurs, mais que ça mange pas mal de mémoire en plus
>>et complexifie un peu le code, à cause du maintien des free_list en
>>dehors des slabs.
>>
>>Quel est ton avis sur la question ?
>>    
>>
>
>Les ctors/dtors ne consomme pas beaucoup de mémoire simplement 2 pointeurs de fonction par structure de cache.
>Ca complexifie un peu le code je te l'accord mais pas à cause du maintien des free_list en dehors des slabs.
>On peut faire des objets construits meme quand la free_list est dans le slab. On augment la taille des objets alloués d'un pointeur pour la free_list (car la free_list est une list simplement chainé) pour casé le pointeur free_list à la fin du buffer comme lorsque l'objet n'est pas construit.
>
>  
>
>>>J'ai constaté une amélioration de la rapidité du calcul de 1000! de 24%
>>>principalement grace au cache coloring.
>>>      
>>>
>>Excellent! Tu as fait tes mesures sur machine réelle ?
>>    
>>
>
>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.
>
>  
>
>>>+    { "kmalloc 8B objects",     8    },
>>>+    { "kmalloc 12B objects",    12   },
>>>+    { "kmalloc 16B objects",    16   },
>>>+    { "kmalloc 20B objects",    20   },
>>>+    { "kmalloc 24B objects",    24   },
>>>+    { "kmalloc 28B objects",    28   },
>>>+    { "kmalloc 32B objects",    32   },
>>>+    { "kmalloc 40B objects",    40   },
>>>+    { "kmalloc 46B objects",    46   },
>>>+    { "kmalloc 52B objects",    52   },
>>>+    { "kmalloc 64B objects",    64   },
>>>+    { "kmalloc 80B objects",    80   },
>>>+    { "kmalloc 96B objects",    96   },
>>>+    { "kmalloc 112B objects",   112  },
>>>+    { "kmalloc 128B objects",   128  },
>>>+    { "kmalloc 160B objects",   160  },
>>>+    { "kmalloc 200B objects",   200  },
>>>+    { "kmalloc 256B objects",   256  },
>>>+    { "kmalloc 340B objects",   340  },
>>>+    { "kmalloc 426B objects",   426  },
>>>+    { "kmalloc 512B objects",   512  },
>>>+    { "kmalloc 768B objects",   768  },
>>>+    { "kmalloc 1024B objects",  1024 },
>>>+    { "kmalloc 1536B objects",  1536 },
>>>+    { "kmalloc 2048B objects",  2048 },
>>>+    { "kmalloc 3072B objects",  3072 },
>>>+    { "kmalloc 4096B objects",  4096 },
>>>+    { "kmalloc 6144B objects",  6144 },
>>>+    { "kmalloc 8192B objects",  8192 },
>>>+    { "kmalloc 9728B objects",  9728 },
>>>      
>>>
>>Ici, il y a une raison particulière qui te fait définir des slabs pour
>>des objets de toutes ces tailles ?
>>    
>>
>
>C'est dans le papier de Bonwick. Il conseil une trentaine de cache de 8B à 9KB qui croissent de 10 à 20%
>  
>
>>>+  /* Compute number of pages per slab */
>>>+  *pages_per_slab = ((8 * *alloc_obj_size) / SOS_PAGE_SIZE) + 1;
>>>      
>>>
>>Ici, le '8' en dur, c'est le nombre d'objets minimum que tu veux avoir
>>dans chaque slab ?
>>    
>>
>
>C'est exactement ça. C'est pas la chose la plus propre que j'ai fait je reconnais.
>
>Anthoine Bourgeois
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Sos mailing list
>Sos at the-doors.enix.org
>http://the-doors.enix.org/cgi-bin/mailman/listinfo/sos
>  
>