Messages in this thread | | | Subject | Re: Rationale for RLIMIT_MEMLOCK? | From | Lee Revell <> | Date | Mon, 23 Jan 2006 14:57:34 -0500 |
| |
On Mon, 2006-01-23 at 19:55 +0100, Matthias Andree wrote: > I'm asking the Bcc'd gentleman to reconsider mlockall() and perhaps > use explicit mlock() instead.
Probably good advice, I have found mlockall() to be especially problematic with multithreaded programs and NPTL, as glibc eats RLIMIT_STACK of unswappable memory for each thread stack which defaults to 8MB here - you go OOM really quick like this. Most people don't seem to realize the need to set a sane value with pthread_attr_setstack().
(Even when not mlock'ed, insanely huge thread stack defaults seem to account for a lot of the visible bloat on the desktop - decreasing RLIMIT_STACK to 512KB reduces the footprint of Gnome 2.12 by 100+ MB.)
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |