| |||||||||||||
Memory compactionMemory compactionPosted Jan 7, 2010 4:48 UTC (Thu) by eparis123 (guest, #59739)Parent article: Memory compaction
That might be a naive question, but I wonder if "reclaiming" a page is synonymous with swapping it to a cache partition, or just simply freeing it if it's already in a clean state in the file system. From the patchset:
When a process fails to allocate a high-order page, it may compact memory in an attempt to satisfy the allocation instead of entering direct reclaim.
And from the article:
Most memory used by the kernel directly cannot be moved - though some of it is reclaimable, meaning that it can be freed entirely on demand
The patchset author also makes the case of less reclaimed pages the selling point of the patchset, so I hope I'm not misunderstanding:
The vanilla kernel had reclaimed 105132 pages at that point. The kernel with compaction had reclaimed 59071, less than half of what the vanilla kernel reclaimed
Thank you
(Log in to post comments)
Memory compaction Posted Jan 7, 2010 7:13 UTC (Thu) by johill (subscriber, #25196) [Link]
I can't really answer the question, but I don't think it matters for the "selling argument" at hand?
Both swapping out a page and freeing something that was recently used has performance impacts, so if you can get away with doing less of that while simultaneously reducing memory fragmentation, that seems like a good thing.
What, as I understand it, Jon says is that if the code finds a page it would like to move, which it cannot do, but it can reclaim that page, it will do that instead of moving it, thereby also freeing it for the contiguous memory block it is creating.
"less than half" ? Posted Jan 7, 2010 17:25 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
59071 is not "less than half" of 105132 although it is "only slightly more than half" and so this isn't important, just a nitpick (or perhaps a misunderstanding on my part)
|
|||||||||||||