On 03.03.2008 [16:50:11 -0600], Andrew Hastings wrote:
> Nish,
>
> Nishanth Aravamudan wrote:
> > Another quick thought: we recently changed elflink.c to fork() to do the
> > hugetlbfs copying. Would such a change be useful in the stack remapping
> > code? That would avoid some of the address spac
Nish,
Nishanth Aravamudan wrote:
> Another quick thought: we recently changed elflink.c to fork() to do the
> hugetlbfs copying. Would such a change be useful in the stack remapping
> code? That would avoid some of the address space pollution issues, I'd
> think, but not sure if it's fully applica
On 22.02.2008 [17:42:58 -0600], Andrew Hastings wrote:
> Nish,
>
> Nishanth Aravamudan wrote:
> 2. Must have address space randomization turned on for i386 and x86_64.
If this is the case, shouldn't you be checking the sysctl in stack.c?
Then we just make the feature depend on the sys
Nish,
Nishanth Aravamudan wrote:
2. Must have address space randomization turned on for i386 and x86_64.
>>> If this is the case, shouldn't you be checking the sysctl in stack.c?
>>> Then we just make the feature depend on the sysctl's value.
>> I'd prefer not to do this -- if my kernel patch
On 22.02.2008 [14:20:13 -0600], Andrew Hastings wrote:
> Nish,
>
> Thanks for the review!
No problem, thanks for working on this code, I think it's a useful
feature.
> Nishanth Aravamudan wrote:
>> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
>>> Remap stack on hugepages if HUGETLB_STAC
On 22.02.2008 [14:20:13 -0600], Andrew Hastings wrote:
> Nish,
>
> Thanks for the review!
Another quick thought: we recently changed elflink.c to fork() to do the
hugetlbfs copying. Would such a change be useful in the stack remapping
code? That would avoid some of the address space pollution iss
Nish,
Thanks for the review!
Nishanth Aravamudan wrote:
> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
>> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
>>
>> Caveats:
>> 1. Hugepage stack does not grow or shrink.
>
> Ok, this may not be a problem we need to addre
On Fri, Feb 08, 2008 at 09:46:09AM -0600, Andrew Hastings wrote:
> David Gibson wrote:
> > On Tue, Feb 05, 2008 at 02:54:03PM -0800, Nishanth Aravamudan wrote:
> >> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
> >>> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
> >>
David Gibson wrote:
> On Tue, Feb 05, 2008 at 02:54:03PM -0800, Nishanth Aravamudan wrote:
>> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
>>> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
>>>
>>> Caveats:
>>> 1. Hugepage stack does not grow or shrink.
>> Ok, this m
On Tue, Feb 05, 2008 at 02:54:03PM -0800, Nishanth Aravamudan wrote:
> On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
> > Remap stack on hugepages if HUGETLB_STACK is set in the environment.
> >
> > Caveats:
> > 1. Hugepage stack does not grow or shrink.
>
> Ok, this may not be a problem
On 05.02.2008 [15:06:22 -0600], Andrew Hastings wrote:
> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
>
> Caveats:
> 1. Hugepage stack does not grow or shrink.
Ok, this may not be a problem we need to address in the short term,
we'll see what users say :)
> 2. Must have a
Remap stack on hugepages if HUGETLB_STACK is set in the environment.
Caveats:
1. Hugepage stack does not grow or shrink.
2. Must have address space randomization turned on for i386 and x86_64.
For i386 and x86_64, the default stack location is at TASK_SIZE and is
not aligned to 2M. The kernel w
Nishanth Aravamudan wrote:
> On 30.11.2007 [16:01:18 -0800], Nishanth Aravamudan wrote:
>> On 30.11.2007 [17:30:06 -0600], Andrew Hastings wrote:
>>> Nishanth Aravamudan wrote:
On 27.11.2007 [16:51:26 -0600], Andrew Hastings wrote:
> +3. Set HUGETLB_STACK= or HUGETLB_STACK=yes
> + Thi
On 30.11.2007 [16:01:18 -0800], Nishanth Aravamudan wrote:
> On 30.11.2007 [17:30:06 -0600], Andrew Hastings wrote:
> > Nishanth Aravamudan wrote:
> >> On 27.11.2007 [16:51:26 -0600], Andrew Hastings wrote:
> >>> +3. Set HUGETLB_STACK= or HUGETLB_STACK=yes
> >>> + This enables the hugepage stack f
On 30.11.2007 [17:30:06 -0600], Andrew Hastings wrote:
> Nishanth Aravamudan wrote:
>> On 27.11.2007 [16:51:26 -0600], Andrew Hastings wrote:
>>> +3. Set HUGETLB_STACK= or HUGETLB_STACK=yes
>>> + This enables the hugepage stack feature, instructing libhugetlbfs
>>> + to remap the main program sta
Nishanth Aravamudan wrote:
> On 27.11.2007 [16:51:26 -0600], Andrew Hastings wrote:
>> +3. Set HUGETLB_STACK= or HUGETLB_STACK=yes
>> + This enables the hugepage stack feature, instructing libhugetlbfs
>> + to remap the main program stack with a hugepage version. Setting
>> + HUGETLB_STACK=yes
On 30.11.2007 [10:40:23 -0600], Steve Fox wrote:
> On Wed, 2007-11-28 at 10:02 -0800, Nishanth Aravamudan wrote:
> > I wonder, what kind of performance impact (positively, that is), this
> > patch has?
>
> I ran a quick (3 pass) test on a Power4 box using the SpecCPU06 bwaves
> test. This test has
On Wed, 2007-11-28 at 10:02 -0800, Nishanth Aravamudan wrote:
> I wonder, what kind of performance impact (positively, that is), this
> patch has?
I ran a quick (3 pass) test on a Power4 box using the SpecCPU06 bwaves
test. This test has a ~1GB stack size. The result was an average of 2.1%
improve
On 27.11.2007 [16:51:26 -0600], Andrew Hastings wrote:
> Remap stack on hugepages if HUGETLB_STACK is set in the environment.
I would prefer a bit more verbose commitlog :)
For instance, a bit on what, if any, caveats there might be (I note
further down that you say that it might not always work?
Remap stack on hugepages if HUGETLB_STACK is set in the environment.
Signed-off-by: Andrew Hastings <[EMAIL PROTECTED]> on behalf of Cray Inc.
---
I've tested this on x86_64 and PPC64.
-Andrew Hastings
Cray Inc.
HOWTO | 74 +
Makefile |2
stack.c
20 matches
Mail list logo
