]] Poul-Henning Kamp
| In message 5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com, Ken Brownfield
wri
| tes:
|
| Would a stack overflow take out the whole child, or just that thread?
|
| The kernel would try to extend the stack and provided you are not on
| a 32 bit system, it shouldn't ever
Overcommit defaults off; sane use cases for overcommit are few and far
between, IMHO. With overcommit on, the performance implications might
be more of a wash... but then you have two problems.
Even though the stack remains mostly unused, it would still have to be
swapped out under memory
When looking at /proc/map info for varnish threads, I'm seeing the
following allocations in numbers that essentially match the child count:
40111000 8192K rw---[ anon ]
And this at almost double the child count:
7f4d5790 1024K rw---[ anon ]
For example, for 64
]] Ken Brownfield
| When looking at /proc/map info for varnish threads, I'm seeing the
| following allocations in numbers that essentially match the child count:
|
| 40111000 8192K rw---[ anon ]
Looks like the default stack size.
| And this at almost double the child count:
|
On Jun 19, 2009, at 7:15 AM, Tollef Fog Heen wrote:
| 40111000 8192K rw---[ anon ]
Looks like the default stack size.
Ah, of course. Good find, thanks. I'm thinking it might be nice to
have a thread track its stack history and emit its approximate largest
size when it's
In message 5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com, Ken Brownfield wri
tes:
Would a stack overflow take out the whole child, or just that thread?
The kernel would try to extend the stack and provided you are not on
a 32 bit system, it shouldn't ever have a problem with that.
--
