[email protected] wrote:
>  On Thu, 15 Sep 2011 11:25:29 -0500, Andrew Hastings wrote:
>> Eric B Munson wrote:
>>> On Wed, 20 Jul 2011, Andrew Hastings wrote:
>>>
>>>> Eric,
>>>>
>>>> On 07/11/11 10:51, Eric B Munson wrote:
>>>>> Transparent huge pages (THP) make using huge pages on x86(_64) 
>>>>> incredibly easy.
>>>>> However, the standard glibc malloc is not setup to optimixe 
>>>>> allocations to be
>>>>> fulfilled as THP, relying on khugepaged to scan and merge huge 
>>>>> pages when
>>>>> possible.  This patch set extends the morecore idea that was 
>>>>> originally used to
>>>>> back the heap with hugetlbfs huge pages to ensure that the heap is 
>>>>> grown in
>>>>> huge page sized increments.  This allows the kernel allocator to 
>>>>> start the new
>>>>> area as a huge page rather than wait for promotion.
>>>>>
>>>>> Eric B Munson (3):
>>>>>   Add support for THP in morecore
>>>>>   Add support to hugeadm for configuring transparent huge pages
>>>>>   Add controls to hugectl for new THP related env variables
>>>>>
>>>>>  HOWTO                   |    7 +++-
>>>>>  hugeadm.c               |  105 
>>>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  hugectl.c               |   17 +++++++-
>>>>>  hugeutils.c             |    4 ++
>>>>>  libhugetlbfs_internal.h |    1 +
>>>>>  man/hugeadm.8           |   35 ++++++++++++++++
>>>>>  man/hugectl.8           |   11 +++++
>>>>>  morecore.c              |   84 
>>>>> +++++++++++++++++++++++++++++++++++--
>>>>>  8 files changed, 258 insertions(+), 6 deletions(-)
>>>> Please consider adding some test cases.
>>>>
>>>> -Andrew Hastings
>>>>  Cray Inc.
>>> I agree that test cases are a good thing for new functionality, but 
>>> I don't see
>>> what could be tested.  THP availablility is completely up to the 
>>> kernel, this
>>> method doesn't guarantee that the heap will be on huge pages, it 
>>> only aligns
>>> allocations so that if there are THP available, they will be used 
>>> without
>>> having to wait for khugepaged to merge them.  So I suppose we could 
>>> test that
>>> every call to brk is 2MB aligned, but I don't see how that could 
>>> ever fail.
>>> Eric
>> I agree, it's hard to make the tests self-verifying.
>>
>> But I'd find it valuable to have tests that at least exercise the
>> code paths in the library, to help catch any breakages (eg segfaults)
>> from future code changes.
>>
>> And each test could report PASS if it finds hugepages on the heap,
>> INCONCLUSIVE if it doesn't; partial information seems better than
>> none.
>>
>> -Andrew Hastings
>> Cray Inc.
> 
> 
>  If it's okay with you, I will merge the latest set and send out a patch 
>  that just exercises the thp heap code.
> 
>  Thanks,
>  Eric

Eric, I certainly don't mind if tests are in a separate patch.

Thanks!
-Andrew Hastings
 Cray Inc.

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to