>>> Merci pour le lien, l'article de Jonathan Corbet est en effet très clair et je comprends un peu mieux le mécanisme.
C'était aussi le premier hyperlien du paragraphe sur le patch de compactage mémoire ;-)
>>> Donc, ai-je loupé une subtilité ?
Non je ne pense pas. Il faut voir que les pages non déplaçables sont relativement rares donc ton premier exemple se produira rarement.
Concernant le second je ne vois pas de faille et donc je te réponds que je ne sais pas :)
A mon avis on est dans le cas indiqué par Mel Gorman ou un algo plus sophistiqué (qui traiterait ce genre de cas) ne vaudrait pas le coup:
"This method is a bit primitive but is easy to understand and greater sophistication would require maintenance of counters on a per-pageblock basis. This would have a big impact on allocator fast-paths to improve compaction which is a poor trade-off".
[^] # Re: Compactage mémoire
Posté par patrick_g (site web personnel) . En réponse à la dépêche Nouvelle version 2.6.35 du noyau Linux. Évalué à 3.
C'était aussi le premier hyperlien du paragraphe sur le patch de compactage mémoire ;-)
>>> Donc, ai-je loupé une subtilité ?
Non je ne pense pas. Il faut voir que les pages non déplaçables sont relativement rares donc ton premier exemple se produira rarement.
Concernant le second je ne vois pas de faille et donc je te réponds que je ne sais pas :)
A mon avis on est dans le cas indiqué par Mel Gorman ou un algo plus sophistiqué (qui traiterait ce genre de cas) ne vaudrait pas le coup:
"This method is a bit primitive but is easy to understand and greater sophistication would require maintenance of counters on a per-pageblock basis. This would have a big impact on allocator fast-paths to improve compaction which is a poor trade-off".
Je t'invite à lire tout son mail de commit qui est très détaillé (avec des benchs plus complets que ce que j'ai indiqué) : http://article.gmane.org/gmane.linux.kernel.mm/47298