From: Paul Brook <paul@codesourcery.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support
Date: Fri, 12 Mar 2010 16:24:24 +0000 [thread overview]
Message-ID: <201003121624.24870.paul@codesourcery.com> (raw)
In-Reply-To: <20100312161724.GT5677@random.random>
> 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
next prev parent reply other threads:[~2010-03-12 16:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-11 15:14 [Qemu-devel] [PATCH QEMU] transparent hugepage support Andrea Arcangeli
2010-03-11 15:52 ` Avi Kivity
2010-03-11 16:05 ` Andrea Arcangeli
2010-03-13 8:28 ` Avi Kivity
2010-03-13 17:47 ` Andrea Arcangeli
2010-03-11 16:28 ` Paul Brook
2010-03-11 16:46 ` Andrea Arcangeli
2010-03-11 17:55 ` Paul Brook
2010-03-11 18:49 ` Andrea Arcangeli
2010-03-12 11:36 ` Paul Brook
2010-03-12 14:52 ` Andrea Arcangeli
2010-03-12 16:04 ` Paul Brook
2010-03-12 16:17 ` Andrea Arcangeli
2010-03-12 16:24 ` Paul Brook [this message]
2010-03-12 16:57 ` Andrea Arcangeli
2010-03-12 17:10 ` Paul Brook
2010-03-12 17:41 ` Andrea Arcangeli
2010-03-12 18:17 ` Paul Brook
2010-03-12 18:36 ` Andrea Arcangeli
2010-03-12 18:41 ` Paul Brook
2010-03-12 18:51 ` Andrea Arcangeli
2010-03-12 22:40 ` Jamie Lokier
2010-03-12 16:10 ` Paul Brook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003121624.24870.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=aarcange@redhat.com \
--cc=avi@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.