On Sun, Apr 11, 2010 at 02:08:00PM +0200, Ingo Molnar wrote: > > * Avi Kivity <avi@xxxxxxxxxx> wrote: > > 3) futility > > I think Andrea and Mel and you demonstrated that while defrag is futile in > theory (we can always fill up all of RAM with dentries and there's no 2MB > allocation possible), it seems rather usable in practice. One problem is that you need to keep a lot more memory free in order for it to be reasonably effective. Another thing is that the problem of fragmentation breakdown is not just a one-shot event that fills memory with pinned objects. It is a slow degredation. Especially when you use something like SLUB as the memory allocator which requires higher order allocations for objects which are pinned in kernel memory. Just running a few minutes of testing with a kernel compile in the background does not show the full picture. You really need a box that has been up for days running a proper workload before you are likely to see any breakdown. I'm sure it's horrible for planning if the RDBMS or VM boxes gradually get slower after X days of uptime. It's better to have consistent performance really, for anything except pure benchmark setups. Defrag is not futile in theory, you just have to either have a reserve of movable pages (and never allow pinned kernel pages in there), or you need to allocate pinned kernel memory in units of the chunk size goal (which just gives you different types of fragmentation problems) or you need to do non-linear kernel mappings so you can defrag pinned kernel memory (with *lots* of other problems of course). So you just have a lot of downsides. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>