On 02/08/2011 08:03 PM, Dan Magenheimer wrote:
(Historical note: This "new" zcache patchset supercedes both the
kztmem patchset and the "old" zcache patchset as described in:
http://lkml.org/lkml/2011/2/5/148)
(In order to move discussion from the old kztmem patchset to
the new zcache patchset, I am replying here to Matt's email
sent at: https://lkml.org/lkml/2011/2/4/199 )
From: Matt [mailto:jackdachef@xxxxxxxxx]
<snip>
â Coming back to usage of compcache - how about the problem of 60%
memory fragmentation (according to compcache/zcache wiki,
http://code.google.com/p/compcache/wiki/Fragmentation) ?
Could the situation be improved with in-kernel "memory compaction" ?
I'm not a developer so I don't know exactly how lumpy reclaim/memory
compaction and xvmalloc would interact with each other
Nitin is the expert on compcache and xvmalloc, so I will leave
this question unanswered for now.
I'm currently in the process of designing a new allocator that gives
predictable memory fragmentation guarantees (at the expense of extra CPU
cycles). I've not yet posted details anywhere but many of the ideas are
from the "Compact Fit" allocator:
http://www.usenix.org/event/usenix08/tech/full_papers/craciunas/craciunas_html/
I'm not sure how much time it will take since I'm not yet done with some
of the design details, and then userspace implementation, testing,
profiling and finally kernel port. Add to that extra concurrency issues
when integrating with zcache!
Thanks,
Nitin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>