On Sat, Jan 27, 2007 at 09:53:54AM -0800, Nishanth Aravamudan wrote:
> On 27.01.2007 [23:37:16 +1100], David Gibson wrote:
> > On Fri, Jan 26, 2007 at 02:44:59PM -0800, Nishanth Aravamudan wrote:
> > > On 26.01.2007 [10:37:03 +1100], David Gibson wrote:
> > > > On Thu, Jan 25, 2007 at 03:24:56PM -0600, Adam Litke wrote:
> > > > > Hmm.  On x86, sometimes gcc will optimize out the alloca() call.  This
> > > > > patch fixes it up nicely.  Please apply.
> > > > > 
> > > > > Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
> > > > > 
> > > > > diff --git a/tests/stack_grow_into_huge.c 
> > > > > b/tests/stack_grow_into_huge.c
> > > > > index fc8a030..7112428 100644
> > > > > --- a/tests/stack_grow_into_huge.c
> > > > > +++ b/tests/stack_grow_into_huge.c
> > > > > @@ -49,6 +49,7 @@ void do_child()
> > > > >  {
> > > > >       while (1) {
> > > > >               alloca(16*1024*1024);
> > > > > +             sleep(0); /* Defeat the gcc optimizer */
> > > > >       }
> > > > >  }
> > > > 
> > > > Hrm, that's a little strangely magical.  I'd suggest instead doing:
> > > >         volatile int *x;
> > > >         x = alloca(lots);
> > > >         *x = 1;
> > > > 
> > > > Then it's clear that the compiler is forbidden from eliding the
> > > > alloca().
> > > 
> > > Agreed, and I prefer this to the barrier() suggestion from Dave. I'll
> > > make this change locally and drop Adam's fix-up patch.
> > 
> > Oh, did realise the only problem with that approach is that it will
> > really truly allocate rather a lot of memory, which might be a problem
> > in some conditions.  That can be addressed by making the alloc() block
> > size larger.
> 
> How much larger do you think it should be than 16M?

Duh, brain failure.  I was reading that as 16k.  16M should be fine.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to