Hi, I'm trying to allocate a large shared memory segment so looking at the virtual memory map for processes. This seems to be something that has plagued Linux for a while, I see Google stuff from Oracle for instance on moving the baseline for shared libraries etc. around to allow a larger SGA. That's all very interesting but when I actually went to look at a real system I found something even stranger.
I have one Intel system running 2.4.21-9.EL and one 390 system under VM also using the same kernel, both are Redhat sourced I believe. When I look at the output from /proc/<x>/maps on the two systems I see very different output. In both cases I see the program text and some associated data area down near the bottom of virtual memory. In both cases I see a smallish piece right at the top of virtual memory (user space) that I assume is for the stack (on Intel this is just under 0xc0000000, on 390 its just under 0x80000000, both as expected). The difference lies in what is in the middle (the spare space and the shared libraries / shared memory area). In the Intel case, I see that the shared libraries are right near the top of the memory map, just under the stack area - this of course leaves a huge hole in the memory map (2.72GB!) just perfect for large shared memory segments. On 390 however, I see the shared libraries stuck slap bang in the middle of the memory map, starting at 0x40000000 (it seems this is how it *was* in Intel but clearly it isn't any longer). Now, with 390 having less user memory already, and those libraries in the middle of the map, allocating shared segments can only be done above them and below the stack, so I'm restricted to a max size smaller than 1GB (actually, the system seems to enforce a limit of more like 749MB). Seems to me we could have more like a 1.7GB space if we moved things around to match Intel. So, do I follow the instructions which I saw in the Oracle info from Google to move the shared libraries down towards the program text? I'm not sure if this is a Redhat specific hack, or whether it's code that is rolling into the mainstream (the ability to change the shared library base on the fly)? I certainly need to stay distributor neutral for my final solution. The 'solution' I observe on my Intel system seems much neater, and I can't for the life of me see why that change would be architecture specific? OK, the user space size is different (2GB on 390, 3GB on Intel) but surely that just makes this situation more important to fix on 390? This is probably the wrong place to ask these questions, but if there is anyone that knows the 390 / Linux internals well enough to (1) explain why 390 hasn't adopted this solution, (2) whether it can and / or will and / or has already in some later level plus (3) whether this solution on Intel is real or some strange configuration done by a colleague to my Intel system without me knowing, then I'd be grateful! Cheers, Innes. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
