Messages in this thread | | | Date | Sat, 19 Jun 2004 01:34:46 -0700 | From | William Lee Irwin III <> | Subject | Re: [patch] flexible-mmap-2.6.7-D5 |
| |
On Sat, Jun 19, 2004 at 09:46:12AM +0200, Ingo Molnar wrote: > the patch already takes care of this via two mechanisms: > - the top of the mmaps is moved down by the expected maximum size of the > stack (the stack rlimit). > - we maintain a minimum 128 MB 'gap' between stack top and mmap top. > moving it to 0x08040000 is asking for trouble, there are people who need > 1GB stacks (dont ask why). This approach has been in production use for > ~2 years and it works fine for a wide range of applications and VM > needs.
I'm not terribly convinced the stack's virtual placement helps in the case where 1GB stacks are needed as within rlimits, it's usually lazily expanded. I suppose the users in need of it adjust their rlimits, say, in the shell spawning the process wanting it to precisely what they need in this scheme, which is awkward, but doesn't require code modification for the offending apps.
Also, I suspect some more graceful fallback would make sense particularly for the case of RLIM_INFINITY, which would leave users that run with, say, all rlimits at RLIM_INFINITY in the interest of having full access to system resources with a mere 512MB of virtualspace for the heap, which IIRC glibc is intelligent enough to circumvent for malloc(), but not for mmap(NULL, ...). If it's been in production that long, I find it hard to believe that's never been tripped over. This is one of the reasons that when I thought about this and split off an isolated patch for top-down vma allocation from execshield, I gave up immediately on the rlimits and said "let them malloc() their own stacks", and shoved the default down low (also, that 128MB is currently wasted); the rlimits appeared to need too precise of tuning and be easy to mis-tune. But that was a matter of thinking about it, not experience.
These are questions whose answers largely do not affect me personally or anything I work on. If the answer is "it suffices as-is" I won't get worked up about it. I didn't raise the RLIM_INFINITY point in my prior post (b/c I missed the rlimit bit), so for the sake of completeness I droned on and on about it here.
Last and definitely least, the declaration in sched.h of functions only used in mmap.c set off some warning flags; it may make sense to just declare the things in mm/mmap.c, possibly with __attribute__((weak)) or some such (AIUI this is now allowed, the last buggy arches' toolchains were fixed, and it's already used now with cond_syscall() etc.). There is a bit of nastiness with sched.h being a "garbage can" header it'd be nice to avoid aggravating.
Thanks.
-- wli - 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/
| |