First of all, the default ulimit (8MiB) can be a bit small so your probably do want to increase the kernel tunable, maxssiz, up to something like 32-64MiB. Even the 64-bit counterpart, maxssiz_64bit very seldom needs to be larger than about 128MiB --- and that is very generous. Well written code almost never needs stacks any larger than this; if you find that you do need stacks larger than these values then almost certainly the code is badly written --- although there could be exceptions (e.g. intentionally, highly recursive algorithms). Most often when larger stacks than ~ 32-64MiB are needed, you are fixing the symptoms rather than fixing the problem --- bad code. If you have set you stack size up to 32-64MiB and you need larger ones for a few applications then one way to have you cake and eat it too is to set maxssiz to some larger value. This will be a global value. You can then use ulimit -S s smaller_value to reduce the stack for users on an individual basis in their .profiles --- or a file sourced by their .profiles.
One major drawback to a larger stack size -- especially for 32-bit applications -- is that the stack and data segment are allocated from the same quadrant. This means that however large you make maxssiz, you reduce the data segment by that much -- even if the run-time stack never approaches the limit.
If it ain't broke, I can fix that.
