On (03/03/08 14:15), Nishanth Aravamudan didst pronounce:
>
>
> > This patch also adds a test case to verify that a process using
> > HUGETLB_MORECORE does not get killed when it exhausts the available
> > free hugepages, assuming sufficient free base pages are available.
> So, is
On 03.03.2008 [16:25:53 -0600], Andrew Hastings wrote:
> Nishanth Aravamudan wrote:
>> On 29.02.2008 [15:29:05 -0600], Andrew Hastings wrote:
>>> Nishanth Aravamudan wrote:
On 29.02.2008 [09:21:22 -0600], Andrew Hastings wrote:
> This raises a side issue -- there's an assumption in the tes
Nishanth Aravamudan wrote:
> On 29.02.2008 [15:29:05 -0600], Andrew Hastings wrote:
>> Nishanth Aravamudan wrote:
>>> On 29.02.2008 [09:21:22 -0600], Andrew Hastings wrote:
This raises a side issue -- there's an assumption in the test suite
that the entire suite is run as superuser. Woul
On 29.02.2008 [15:29:05 -0600], Andrew Hastings wrote:
> Nish,
>
> Nishanth Aravamudan wrote:
>> On 29.02.2008 [09:21:22 -0600], Andrew Hastings wrote:
>>> Yes... SLES10 doesn't have the dynamic pool, unfortunately. Our
>>> customers have such a variety of jobs that there isn't one hugepage
>>> po
On 29.02.2008 [14:49:58 -0600], Dean Luick wrote:
> Hi Nishanth,
>
> I'll pipe up here since I ran into this directly.
>
>
> On Fri, Feb 29, 2008 at 10:33:16AM -0800, Nishanth Aravamudan wrote:
> > >>> 2. Most distros have a default mlock limit well below the size of
> > >>> one hugepage.
Nish,
Nishanth Aravamudan wrote:
> On 29.02.2008 [09:21:22 -0600], Andrew Hastings wrote:
>> Yes... SLES10 doesn't have the dynamic pool, unfortunately. Our
>> customers have such a variety of jobs that there isn't one hugepage
>> pool size that will work for all applications. With the 2.16 kern
Hi Nishanth,
I'll pipe up here since I ran into this directly.
On Fri, Feb 29, 2008 at 10:33:16AM -0800, Nishanth Aravamudan wrote:
> >>> 2. Most distros have a default mlock limit well below the size of
> >>> one hugepage. (The kernel default is 8 base pages.)
> >> We usually advise custo
On 29.02.2008 [09:21:22 -0600], Andrew Hastings wrote:
> Nish,
>
> Thanks for the feedback!
>
> Nishanth Aravamudan wrote:
>> On 27.02.2008 [16:12:14 -0600], Andrew Hastings wrote:
>>> hugetlbfs_morecore() is currently calling mlock() presumably to
>>> instantiate newly-mapped hugepages before retu
Nish,
Thanks for the feedback!
Nishanth Aravamudan wrote:
> On 27.02.2008 [16:12:14 -0600], Andrew Hastings wrote:
>> hugetlbfs_morecore() is currently calling mlock() presumably to
>> instantiate newly-mapped hugepages before returning to malloc().
>>
>> However, this is ineffective for two reas
On 27.02.2008 [17:02:15 -0800], Nishanth Aravamudan wrote:
> On 27.02.2008 [16:12:14 -0600], Andrew Hastings wrote:
> > hugetlbfs_morecore() is currently calling mlock() presumably to
> > instantiate newly-mapped hugepages before returning to malloc().
> >
> > However, this is ineffective for two
On 27.02.2008 [16:12:14 -0600], Andrew Hastings wrote:
> hugetlbfs_morecore() is currently calling mlock() presumably to
> instantiate newly-mapped hugepages before returning to malloc().
>
> However, this is ineffective for two reasons:
> 1. The return value of mlock is ignored. If there aren't
hugetlbfs_morecore() is currently calling mlock() presumably to
instantiate newly-mapped hugepages before returning to malloc().
However, this is ineffective for two reasons:
1. The return value of mlock is ignored. If there aren't enough
hugepages available, the process may be killed later,
12 matches
Mail list logo
