On Mon, Apr 12, 2010 at 09:36:23AM +0300, Avi Kivity wrote: > On 04/12/2010 09:09 AM, Nick Piggin wrote: > > 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. > > It's the usual space-time tradeoff. You don't want to do it on a > netbook, but it's worth it on a 16GB server, which is already not very > high end. Agreed. BTW, if booting with transparent_hugepage=0, set_recommended_min_free_kbyte in-kernel logic won't run automatically during the late_initcall invocation. > Non-linear kernel mapping moves the small page problem from userspace > back to the kernel, a really unhappy solution. Yeah, so we have hugepages in userland but we lose them in kernel ;) and we run kmalloc as slow as vmalloc ;). I think kernelcore= here is the answer when somebody asks the math guarantee. We should just focus on providing a math guarantee with kernelcore= and be done with it. Limiting the unmovable caches to a certain amount of RAM is orders of magnitude magnitude more flexible and transparent (and absolutely unnoticeable) than having to limit only hugepages (so unusable as regular anon memory, or regular pagecache, or any other movable entitiy) to a certain amount at boot (plus not being able to swap them, having to mount filesystems, using LD_PRELOAD tricks etc...). Furthermore with hypervisor usage the unmovable stuff really isn't a big deal (1G is more than enough for that even on monster servers) and we'll never care or risk to hit on the limit. All we need is the movable memory to grow freely and dynamically and being able to spread all over the RAM of the system automatically as needed. -- 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>