[m-dev.] Mercury and GCC split stacks

[Paul Bone]

On Mon, Sep 08, 2014 at 05:28:50AM +0200, Zoltan Somogyi wrote:
> On Mon, 8 Sep 2014 12:12:05 +1000, Paul Bone <paul at bone.id.au> wrote:
> 
> > > The best way to avoid such problems is to use whatever support for large pages
> > > (sometimes called superpages) the TLB supports, since in that case a TLB entry
> > > can map e.g. 4Mb, not just e.g. 4kb.
> > 
> > Ah, so you can trade-off between TLB utilisation and address space
> > utilisation.  Which is good because the latter is under much less pressure.
> 
> Unfortunately, this does not work very well either. The number of superpages
> you can use is typically a small fixed number, so the "tradeoff" is not
> very flexible. (Superpages were initially intended only for mapping
> the kernel's code and data structures.)
> 
> > What if your stack segments were 4MB in size (or a multiple) plus 4kb for
> > the protected page and were 4MB aligned.
> 
> You could do this, but only until you ran out of the small number
> of superpages you are allowed. This number is in the single, maybe double
> digits on current and foreseeable machines; the 10,000 threads
> you were talking about in an earlier email are right out.
> 

Oh, Is that a hardware limitation?

If superpages are rarely applicable because of a limitation like this, then
they're going to be rarely used to decrease TLB usage.  Which means using a
protected page at the end of each stack segment, especially when that
protected page is in a different 4MB area, may not decrease the amount
that superpages are actually used.

I agree that using protected memory to check for stack overflow is not
universally a good idea.  I'm happy to agree that we'd need to test and
compare this with the current approach, and that the program and environment
will strongly contribute to which approach is best.

Either way, this is probably not our low-hanging fruit.


-- 
Paul Bone