On Thu, Mar 15, 2007 at 11:08:40PM +, Hugh Dickins wrote:
> > appears to increase Committed_AS by around 200kb. But we've committed to
> > providing it with 8MB for stack.
> >
> > How come this is correct?
>
> We've no more committed to providing each instance with 8MB of stack,
> than
On Thu, Mar 15, 2007 at 11:08:40PM +, Hugh Dickins wrote:
appears to increase Committed_AS by around 200kb. But we've committed to
providing it with 8MB for stack.
How come this is correct?
We've no more committed to providing each instance with 8MB of stack,
than we've committed
On Thu, 15 Mar 2007 11:06:21 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > This question is relevent to 2.6.20.
> >
> > I noticed that if the RSS for the stack size is say, 8MB, running
> > a
> > > With a typical size as a fuzz factor preaccounted in later kernels.
> >
> > Where's that done?
>
> I don't know what Alan is referring to there.
fs/exec.c - we add 20 pages to the stack vma size initially.
> We've no more committed to providing each instance with 8MB of stack,
> than
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()
> {
>
On Thu, 15 Mar 2007, Andrew Morton wrote:
> On Thu, 15 Mar 2007 23:33:43 +
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > > 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
On Thu, 15 Mar 2007 23:33:43 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > 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
> 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.
With a typical size as a fuzz factor preaccounted in
On 3/15/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
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.
Please all, forget about MAP_GROWSDOWN.
On Thu, 15 Mar 2007, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni <[EMAIL PROTECTED]> 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,
> On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This question is relevent to 2.6.20.
>
> I noticed that if the RSS for the stack size is say, 8MB, running
> a single-threaded process doesn't incur an increase of 8MB to
> Committed_AS (/proc/meminfo).
>
>
On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni [EMAIL PROTECTED] wrote:
Hello,
This question is relevent to 2.6.20.
I noticed that if the RSS for the stack size is say, 8MB, running
a single-threaded process doesn't incur an increase of 8MB to
Committed_AS (/proc/meminfo).
However, on
On Thu, 15 Mar 2007, Andrew Morton wrote:
On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni [EMAIL PROTECTED] 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,
On 3/15/07, Hugh Dickins [EMAIL PROTECTED] wrote:
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.
Please all, forget about MAP_GROWSDOWN.
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.
With a typical size as a fuzz factor preaccounted in
On Thu, 15 Mar 2007 23:33:43 +
Alan Cox [EMAIL PROTECTED] wrote:
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
On Thu, 15 Mar 2007, Andrew Morton wrote:
On Thu, 15 Mar 2007 23:33:43 +
Alan Cox [EMAIL PROTECTED] wrote:
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
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
With a typical size as a fuzz factor preaccounted in later kernels.
Where's that done?
I don't know what Alan is referring to there.
fs/exec.c - we add 20 pages to the stack vma size initially.
We've no more committed to providing each instance with 8MB of stack,
than we've
On Thu, 15 Mar 2007 11:06:21 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni [EMAIL PROTECTED] wrote:
Hello,
This question is relevent to 2.6.20.
I noticed that if the RSS for the stack size is say, 8MB, running
a single-threaded process
20 matches
Mail list logo
