May 10 11:27:58 <markmc>	jakub, where is the default for RLIMIT_STACK defined ?
May 10 11:28:07 <markmc>	jakub, and any reason its 10M ?
May 10 11:28:34 <jakub>	markmc: in the kernel
May 10 11:28:50 <markmc>	jakub, people are getting freaked out at the 10M jump in some the total mapped memory size of GNOME processes
May 10 11:28:53 <jakub>	markmc: and can be overridden in login config files, sh profile etc.
May 10 11:29:02 <markmc>	jakub, because we've introduced an extra thread ...
May 10 11:29:45 <roland>	use pthread attrs set the stacksize to what you need
May 10 11:29:46 <jakub>	markmc: it is 10M because 8M is a good compromise between too small and too large stack and 2M for stack randomization
May 10 11:30:00 <arjan>	markmc: why would 10Mb be a problem ?
May 10 11:30:14 <arjan>	(it's always been in that order fwiw)
May 10 11:30:27 <markmc>	arjan, people are just getting freaked out by the extra "bloat"
May 10 11:30:32 *	markmc finds the link
May 10 11:30:36 <arjan>	it's only VSS not memory
May 10 11:31:01 <markmc>	http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00052.html
May 10 11:31:14 <markmc>	arjan, right, I get that
May 10 11:31:45 <markmc>	arjan, there has been a drop in rss, so ... :)
May 10 11:32:07 <roland>	if you have a multithreaded program and you know that your threads stack use is small, it's always a fine thing to set the pthread attr to just what you need
May 10 11:32:11 <arjan>	anyway if you don't want that set your stack size yourself
May 10 11:32:43 <jakub>	markmc: but surely, if you don't need that much, use say 256K or 512K stack...
May 10 11:32:52 <markmc>	yeah, so how on earth can you decide a reasonable stack size for your thread ?
May 10 11:33:20 <roland>	it helps if you know what code you are going to call
May 10 11:34:54 <markmc>	its pretty much your typical "read from socket, signal to main thread to handle data in idle" thread
May 10 11:35:07 <markmc>	so, definitely never a deep call stack
May 10 11:35:14 <arjan>	markmc: for reference the kernel uses 4Kb stack size nowadays ;)
May 10 11:35:14 <markmc>	doesn't seem to allocate much on the stack ...
May 10 11:35:54 <roland>	pthread stacks have a guard page, so you can safely tune it down small and if it turns out to be too small, you'll crash obviously instead of scribbling confusingly
May 10 11:35:58 <jakub>	markmc: depth of call stack is one thing, the other is if you ever allocate large buffers on the stack, or use VLAs/alloca
May 10 11:36:47 <jakub>	markmc: not that the minimal stack size differs on different arches, so e.g. on ia64 you should not go close to 128K or smaller
May 10 11:36:50 <markmc>	jakub, right, not seeing any of that
May 10 11:37:07 <jakub>	markmc: 256K should be ok.  Other arches might need less, but then, 256K is not much
May 10 11:37:20 <markmc>	jakub, okay, will do
May 10 11:37:22 <markmc>	thanks guys
May 10 11:37:43 <jakub>	markmc: or if you call any glibc function that use alloca internally (glibc tries to limit itself in several places, but not all)
May 10 11:38:12 <jakub>	markmc: e.g. if you use stdio with wide strings, or wide stdio, you might need to take that into account
May 10 11:38:22 <markmc>	jakub, ah
May 10 11:38:30 <markmc>	jakub, this is a hard limit, right ?
May 10 11:38:38 <markmc>	jakub, if we set it too low, we'll see SEGVs ?
May 10 11:38:51 <roland>	markmc: right
May 10 11:38:57 <markmc>	cool
May 10 11:39:09 <jakub>	markmc: yes.  By default there is a pagesize of unmapped bytes (guard page), so underflow should be segfault
May 10 11:39:46 <markmc>	thanks again
