On Mon, Apr 12, 2010 at 09:40:54AM -0700, Linus Torvalds wrote:
> Yet now, the possibility of _truly_ wasting memory isn't apparently even a
> blip on anybody's radar. People blithely talk about changing glibc default
> behavior as if there are absolutely no issues, and 2MB chunks are pocket
> change.
This is about enabled=always, in some cases we'll waste memory in the
hope to run faster, correct.
> I can pretty much guarantee that every single developer on this list has a
> machine with excessive amounts of memory compared to what the machine is
> actually required to do. And I just do not think that is true in general.
If this is the concern about general use, it's enough to make the
default:
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
and then only madvise(MADV_HUGEPAGE) (like qemu guest physical memory)
will use it, and khugepaged will _only_ scan madvise regions. That
guarantees zero RAM waste, and even a 128M embedded definitely should
enable and take advantage of it to squeeze a few cycles away from a
slow CPU. It's a one liner change.
I should make the default selectable at kernel config time, so
developers can keep it =always and distro can set it =madvise (trivial
to switch to "always" during boot or with kernel command line). Right
now it's =always also to give it more testing btw.
Also note about glibc, our target is to replace libhugetlbfs and
pratically make libhugetlbfs the default. Applications calling mmap
and not passing through malloc, or using libs not possible to
override, will also not be able to take advantage of libhugetlbfs so
that's ok. If somebody scatters 4k mappings all over the virtual
address space of a task, I don't like to allocate 2M pages for those
4k virtual mappings (even if it'd be possible to reclaim them pretty
fast without I/O), though even that is theoretically possible. I just
prefer to have a glibc that cooperates, just like libhugetlbfs
cooperates with hugetlbfs.
--
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>