Hi all,
This post is a request for clarification on some features of libhugetlbfs.
I realize that this mailing list is not intended for this kind of help
demand, but after searching unsuccessfully in the mailing list archive,
reading the man pages of hugetlbfs, hugeadm and hugectl, as well as the
Hello Eric,
It's been ages... Thanks for answering.
I have another question please : do you think it would be feasible to limit
the number of hugepages per section (*) within libhugetlbfs ? Do you see
anything that could prevent from implementing that ?
(*) I mean per vm area, not only per secti
Hi all,
Just a question here : do you see any pitfall that could prevent from
backing a given segment with different hugepage sizes ? (since it already
does it with the fallback mechanism to standard 4K pages).
Thanks,
Telenn
---
Making some tests with libhugetlbfs on kernel 2.6.34, backing automatically
the heap, we realized that the fallback mechanism is all-or-nothing : if
there's not enough hugepages, the whole asked memory is backed by base
pages.
We expected libhugetlbfs to mix hugepages / basepages in such a case. W
On Thu, Nov 15, 2012 at 3:34 PM, Eric B Munson wrote:
> On 2012-11-15 03:42, telenn barz wrote:
>
>> Making some tests with libhugetlbfs on kernel 2.6.34, backing
>> automatically the heap, we realized that the fallback mechanism is
>> all-or-nothing : if theres not eno
On Fri, Nov 16, 2012 at 1:13 AM, David Gibson
wrote:
> On Thu, Nov 15, 2012 at 04:31:44PM -0500, Eric B Munson wrote:
> > On 2012-11-15 14:44, telenn barz wrote:
> > > On Thu, Nov 15, 2012 at 3:34 PM, Eric B Munson > > [1]>
> > > wrote:
> > >
