>> What is the "current usage" of the stack?  I'd argue it's where the
>> stack pointer points, not the amount of VM presently allocated to
>> the stack
> I suppose that depends whether you view the stack size limit from the
> kernel's perspective ("memory have I allocated for this process's
> stack") or the application's point of view ("stack space am I using
> now").

I would say that a bias towards the latter view is already present in
the kernel, in the form of pushing frames for signal delivery, which
assumes that anything below the current stack pointer is freely
garbageable.

> If the stack size were to be able to be reduced below the actual
> allocated size (i.e. set to some value > 10KB and < 1MB in your
> example) should the allocated but unused memory then be released, or
> just made inaccessible (which is what I think the current code does)?

Ideally, of course, it should be released.  At first, it's probably
easier to just make it inaccessible.  (Indeed, I would go farther, and
say that in a tight-memory situation, the kernel should be at liberty
to reclaim any memory presently allocated to stack segments but not
presently in use from an application POV.  Signal stacks complicate
this, and I admittedly haven't thought it out much yet....)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B