Nishanth Aravamudan wrote:
> On 16.08.2006 [16:45:22 +0100], Andy Whitcroft wrote:
>> Adam Litke wrote:
>>> On Wed, 2006-08-16 at 08:12 -0700, Nishanth Aravamudan wrote:
>>>> On 16.08.2006 [10:11:37 +0100], Andy Whitcroft wrote:
>>>>> Nishanth Aravamudan wrote:
>>>>>> morecore's comments indicate that we will failover to smallpage malloc
>>>>>> if we run out of hugepages at runtime, but that is not the case. Modify
>>>>>> one comment and remove another to not confuse anyone.
>>>>>>
>>>>>> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
>>>>>>
>>>>>> diff --git a/morecore.c b/morecore.c
>>>>>> index 9f13316..08a356b 100644
>>>>>> --- a/morecore.c
>>>>>> +++ b/morecore.c
>>>>>> @@ -45,8 +45,8 @@ static long mapsize;
>>>>>> * pretend there are none this covers us for the case where another
>>>>>> * map is in the way. This is required because 'morecore' must have
>>>>>> * 'sbrk' semantics, ie. return sequential, contigious memory blocks.
>>>>>> - * Luckily, if it does not do so and we error out malloc will happily
>>>>>> - * go back to small pages and use mmap to get them. Hurrah.
>>>>>> + * Sufficient hugepages must be allocated before the malloc calls, or
>>>>>> + * the application will be killed.
>>>>> Hmmm, that is a tricky one. If morecore does return failure then the
>>>>> malloc library will do all the things mentioned. The problem here is
>>>>> that with demand fault semantics we will say 'yes' and return a page
>>>>> which can't be instantiated.
>>>>>
>>>>> The comment in and of itsself is correct IMO. Your caveat is
>>>>> appropriate though in addition.
>>>> Description: morecore's comments indicate that we will failover to
>>>> smallpage malloc if we run out of hugepages at runtime. While that is
>>>> the case, the semantics of demand faulting require sufficient hugepages
>>>> exist before the malloc calls. Add a comment to that effect to make it
>>>> clear.
>>>>
>>>> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
>>>>
>>>> diff --git a/morecore.c b/morecore.c
>>>> index 9f13316..4b222ed 100644
>>>> --- a/morecore.c
>>>> +++ b/morecore.c
>>>> @@ -46,7 +46,9 @@ static long mapsize;
>>>> * map is in the way. This is required because 'morecore' must have
>>>> * 'sbrk' semantics, ie. return sequential, contigious memory blocks.
>>>> * Luckily, if it does not do so and we error out malloc will happily
>>>> - * go back to small pages and use mmap to get them. Hurrah.
>>>> + * go back to small pages and use mmap to get them. Hurrah. However,
>>>> + * sufficient hugepages must be allocated before the malloc calls, or
>>>> + * the application will be killed.
>>>> */
>>> How about this:
>>>
>>> * go back to small pages and use mmap to get them. Hurrah. However,
>>> * due to the semantics of demand faulting combined with MAP_PRIVATE
>>> mappings in newer kernels, we are unable to detect the out of huge pages
>>> condition and cannot return an error to glibc for that case. The result
>>> is that when enough huge pages don't exist to satisfy the application's
>>> requirements, it may be killed at runtime.
>>>
>> I'd also make the "However" clause a separate paragraph. /me had more
>> this in mind ...
>
> Works for me :)
Ok, we have all this talk about how it all goes bang and doesn't work...
but then there was this commit below, which I'd expect to restore the
semantic? Or did I miss something.
-apw
commit 3da5975d7e12aebd8d7614f48d8c0d68c6a03146
Use mlock to reserve newly allocated hugepages in hugetlb_morecore.
Since MAP_PRIVATE allocations are full overcommit, the mmap call
can succeed even if there aren't enough huge pages to satisfy the
mapping. Thus fallback
to normal pages is not currently possible. Use mlock to
instantiate the newly
allocated area and if that fails, release it and initiate fallback
to normal pages.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
