[Top][All Lists]

[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 17:10:54 +0000
User-agent: KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; )

> > So shouldn't [the name of] the value the kernel provides for recommended
> > alignment be equally implementation agnostic?
> Is sys/kernel/mm/transparent_hugepage directory implementation
> agnostic in the first place?

It's about as agnostic as MADV_HUGEPAGE :-)

> If we want to fully take advantage of the feature (i.e. NPT and qemu
> first 2M of guest physical ram where usually kernel resides) userspace
> has to know the alignment size the kernel recommends.

This is KVM specific, so my gut reaction is you should be asking KVM.

> Only thing I'm undecided about is if this should be called
> hpage_pmd_size or just hpage_size. Suppose amd/intel next year adds
> 64k pages too and the kernel decides to use them too if it fails to
> allocate a 2M page. So we escalate the fallback from 2M -> 64k -> 4k,
> and HPAGE_PMD_SIZE becomes 64k. Still qemu has to align on the max
> possible hpage_size provided by transparent hugepage. So with this new
> reasoning I think hpage_size or max_hpage_size would be better sysfs
> name for this. What do you think? 


> hpage_size or max_hpage_size?

No particular preference. Or you could have .../page_sizes list all available 
sizes, and have qemu take the first one (or last depending on sort order).


reply via email to

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