On Thu, Mar 15, 2007 at 03:36:13PM -0700, Andrew Morton wrote:
>
> > > > > Is this the intended behaviour?
> > > >
> > > > That sounds like a bug to me.
> > >
> > > I'm suspecting it's an oddity rather than a bug.
> >
> > It is intended behaviour.
>
> Each instance of
>
> main()
> {
> sleep(100);
> }
>
> appears to increase Committed_AS by around 200kb. But we've committed to
> providing it with 8MB for stack.
>
> How come this is correct?
Perhaps it makes a lot of sense if you regard stack growth at
the same sense that you regard heap growth by the means of brk().
Just by the fact that the stack is limited on default and RLIMIT_DATA
is unlimited, doesn't mean the we need to account for the maximum
stack size.
Perhaps for embedded systems where you want to have overcommit_memory=2
overcommit_ratio=100 and no swap (for design constraints), just to make
sure that allocations fail *always before* OOM gets triggered (and
therefore OOM never gets triggered, thankfully), it would have been
useful to look at Commited_AS to realize how much the system is close
to the maximum memory utilization potential.
Learning about this 'oddity' in Commited_AS, I'd guess it would be
better for me not to rely on it for measurements and perhaps tweak
smaller values of RSS_STACK for processes on that embedded system.
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
