On Thu, Apr 15, 2010 at 03:56:11PM +0900, KAMEZAWA Hiroyuki wrote:
Ok so I'll stick to my original patch on aa.git:
http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=patch;h=f0a05fea58501298ab7b...
I already also merged the move from /proc to debugfs from Mel of two
files. So now I've to:
1) finish the generic doc in Documentation/ (mostly taken from
transparent hugepage core changeset comments here:
http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=commit;h=b901f7e1ab412241d42...
)
2) add alloc_pages_vma for numa awareness in the huge page faults
3) have the kernel stack 2m aligned and growsdown the vm_start in 2m
chunks when enabled=always. I doubt it makes sense to decouple this
feature from enabled=always and to add a special sysfs control for
it, plus I don't like adding too many apis and it can always
decoupled later.
4) I think I will not add a prctl to achieve Ingo's per-process enable
for now. I'm quite convinced in real life madvise is enough and
enabled=always|madvise|never is more than enough for the testing
without having to add a prctl. This is identical issue to KSM after
all, in the end also KSM is missing a prctl to enabled merging on a
per process basis and that's fine. prctl really looks very much
like libhugetlbfs to me so I'm not very attracted to it as I doubt
its usefulness strongly and if I add it, it becomes a
forever-existing API (actually even worse than the sysfs layout
from the kernel API point of view) so there has to be a strong
reason for it. And I don't think there's any point to add a
madvise(MADV_NO_HUGEPAGE) or a prctl to selectively _disable_
hugepages on mappings or processes when enabled=always. It makes no
sense to use enabled=always and then to disable hugepages in a few
apps. The opposite makes sense to save memory of course! I don't
want to add kernel APIs in prctl useful only for testing and
benchmarking. It can always be added later anyway...
5) Ulrich sent me a _three_ liner that will make glibc fully cooperate
and guarantee all anon ram goes in hugepages without using
khugepaged (just like libhugetlbfs would cooperate with
hugetlbfs). For the posix threads it won't work yet and for that we
may need to add a MAP_ALIGN flag to mmap (suggested by him) to be
optimal and not waste address space on 32bit archs. That's no big
deal, it's still orders of magnitude simpler that backing an
mmap(4k) with a 2M page and collect the still unmapped parts of
the 2M pages when system is low on memory. Furthermore MAP_ALIGN
will involve the mmap paths with mmap_sem write mode, that aren't
really fast paths, while the mmap(4k) backed by 2M would slowdown
do_anonymous_pages and other core fast paths that are much more
performance critical than the mmap paths. So I think this is the
way to go. And if somebody don't want to risk wasting memory the
default should be enabled=madvise and then add madvise where
needed. One either has to choose between performance and memory,
and I don't want intermediate terms like "a bit faster but not as
fast as it can be, but waste a little less memory" which also
complicates the code a lot and microslowdown the fast paths.
6) add a config option at kernel configuration time to select the
transparent hugepage default between always/madvise/never
(in-kernel set_recommended_min_free_kbytes late_initcall() will be
running only for always/madvise, as it already checks the built time
default and it won't run unless enabled=always|madvise).
--
