qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support


From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support
Date: Fri, 12 Mar 2010 16:24:24 +0000
User-agent: KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; )

> On Fri, Mar 12, 2010 at 04:04:03PM +0000, Paul Brook wrote:
> > > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > > > 2097152
>
> > Hmm, ok. I'm guessing linux doesn't support anything other than "huge"
> > and "normal" page sizes now, so it's a question of whether we want it to
> > expose current implementation details, or say "Align big in-memory things
> > this much for optimal TLB behavior".
> 
> hugetlbfs already exposes the implementation detail. So if you want
> that it's already available. The whole point of going the extra mile
> with a transparent solution is to avoid userland to increase in
> complexity and to keep it as unaware of hugepages as possible. The
> madvise hint basically means "this won't risk to waste memory if you
> use large tlb on this mapping" and also "this mapping is more
> important than others to be backed by hugepages". It's up to the
> kernel what to do next. For example right now khugepaged doesn't
> prioritize scanning the madvise regions first, it basically doesn't
> matter for hypervisor solutions in the cloud (all anon memory in the
> system is only allocated by kvm...). But later we may prioritize it
> and try to be smarter from the hint given by userland.

So shouldn't [the name of] the value the kernel provides for recommended 
alignment be equally implementation agnostic?

Paul




reply via email to

[Prev in Thread] Current Thread [Next in Thread]