Re: thread stacks and strict vm overcommit accounting

[Hugh Dickins <hugh@veritas.com>]

On Thu, 15 Mar 2007, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni <da-x@monatomic.org> wrote:
> > 
> > This question is relevent to 2.6.20.
> > 
> > I noticed that if the RSS for the stack size is say, 8MB, running

I think you meant to say RLIMIT_STACK rather than RSS, didn't you, Dan?

> > a single-threaded process doesn't incur an increase of 8MB to
> > Committed_AS (/proc/meminfo).

Stack RSS should certainly be included in Committed_AS,
but RLIMIT_STACK merely limits how big the stack vma may grow to:
at any moment the stack vma is probably very much smaller,
and only its current size is accounted in Committed_AS.

> > 
> > However, on multi-threaded apps linked with pthread (on Debian
> > Etch with 2.6.20 vanilla x86_64), every thread will incur the
> > the specified maximum stack size RSS (assuming that you use
> > the default attr). In other words, it appears that vm accounting
> > works differently in that case.

I'm guessing that the pthread stacks are mmap'ed as greatest extents
(probably because that's the easiest way to keep them apart), rather
than as small MAP_GROWSDOWN areas to be expanded later on fault.
If so, then those would indeed account the maximum in Committed_AS.

> > 
> > Is this the intended behaviour?
> 
> That sounds like a bug to me.

I'm suspecting it's an oddity rather than a bug.

Hugh