Re: Finding kernel memory starting address on HPUX 11.0
dmorris_at_cup.hp.com
Date: 09/10/03
- Next message: dmorris_at_cup.hp.com: "Re: Memory Management HP-UX 10.20"
- Previous message: Dave Steele: "Oracle 7.3.4 and HP-UX 11i PA-RISC"
- In reply to: Manish Baronia: "Re: Finding kernel memory starting address on HPUX 11.0"
- Next in thread: Manish Baronia: "Re: Finding kernel memory starting address on HPUX 11.0"
- Reply: Manish Baronia: "Re: Finding kernel memory starting address on HPUX 11.0"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 10 Sep 2003 07:29:12 -0600
Manish Baronia <manishbaronia@hotmail.com> wrote:
> Rick Jones wrote:
>> PA-RISC systems do not run a "flat" address space, so if I have
>> understood everything correctly, your mechanism will not work.
>>
>> What do you intend to do with the kernel starting address?
>>
>> rick jones
>> --
>> portable adj, code that compiles under more than one compiler
>> these opinions are mine, all mine; HP might not want them anyway... :)
>> feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
> OK,
> So basic assumptions in this code are wrong. I wanted to know "hard"
> limits till which my process can
> grow. Can someone tell me how to get this limit in C?
> Manish
man getrlimit.
If you're talking about total process size, you want RLIMIT_AS.
Stack growth is (unsurprisingly) RLIMIT_STACK. Heap is RLIMIT_DATA.
What sets the stack, data (and text) limits initially are the
tunables maxssiz, maxdsiz, and maxtsiz [respectively]. 64-bit
limits spawn from maxssiz_64bit, maxdsiz_64bit and maxtsiz_64bit.
There are man pages for these tunables up on docs.hp.com -- SAM
should also have some information on them. (The man pages are
included in 11i v1.6 and higher)
There aren't really enforced sizes on shared memory usage (or anonymous
private mmaps) other than the cap on address space - though your
process will never get more than shmseg * shmmax of shared memory
by simple logic. pstat_getipc() will hand back those values on
11.0 -- or you can just use gettune() if you're on 11.11.
Again - as with all kernel tunables, SAM or docs.hp.com will
have more information on these tunables.
If you want a more theoretical description, then here's a brief
view of the address space layout on PA (which imposes certain
limits):
For "normal" 32-bit processes:
0x00000000
Text
0x40000000
Data (Heap, Private mmap)
0x80000000 -
min(maxssiz, parent's stack limit [if modified])
Stack (grows toward higher addresses)
0x80000000
Shared Objects (SysV Shmem, Shared mmap)
0xC0000000
More Shared Objects
0xF0000000
Memory Mapped I/O
0xFFFFFFFF
It is important to know that *no* memory object may cross
the 1Gb "quadrant" boundaries. So you can't have a 32-bit
shared memory object larger than 1Gb (though if you're very
lucky you may get one 1Gb and another at about .6Gb.. shared
libraries are going to make it pretty much impossible to get
anywhere else).
There are other flavors (SHARE_MAGIC, q3 private, q4 private)
that are basically just shifting things around to get more
private or shared address space - but you have to compile
specifically for them (or use chatr) and I'll let you read
up on the documentation on them yourself. You can also
use Memory Windows to have non-global shared memory views
(to get more shared space for a group of processes working
together) -- there's a white paper on Memory Windows that
I believe shipped with 11.0 (and would still be included
and up to date for 11.11).
So you can see that for a normally compiled 32-bit PA-RISC
application, you will never get more than 1.75Gb total of
shared memory (libraries, SysV shmem, shared MMF) because
of address space limits. Likewise, you can't get more than
1Gb of text with normal compilation or more than slightly
less than 1Gb of heap/private data (slightly less because
the stack will need at least a page).
64-bit processes have a similar layout, with a larger space
and some things moved around:
0x00000000'00000000
64-bit only shared objects
0x00000000'C0000000
32/64-bit shared objects
(+ gateway page)
0x00000000'F0000000
32/64-bit shared MMIO
0x00000001'00000000
64-bit only shared MMIO
0x00000020'00000000
More 64-bit shared objects
0x00000400'00000000
End of quadrant boundary (4Tb)
0x40000000'00000000
Text
0x40000400'00000000
End of text quadrant (4Tb)
0x80000000'00000000
Data (Heap, Private mmap)
0x80000400'00000000
End of data quadrant (4Tb)
0xC0000000'00000000
Even more 64-bit shared objects
0xC0000400'00000000
End of quadrant (4Tb)
You'll notice two things - first, the equivalent to the fourth
quadrant of 32-bit programs is moved to the first quadrant in
64-bit, allowing 32/64-bit mixed-mode sharing without aliasing.
Second, the whole 64-bit virtual address space isn't used -- just
16Tb of it.
You'll notice the kernel is nowhere to be seen in the above -
and that's because the kernel operates in the _real_ address
space underlying all of the user ones -- the Global Virtual
Address Space. Only the kernel works with full Global Virtual
Addresses - users never see them. The user virtual address is
manipulated to form the offset portion of their GVA, the other
half is the space identifier for the piece of the user address
space, which is allocated and manipulated by the kernel. The
kernel uses private space ids for it's text/data/whatnot.
Don
-- Quidquid latine dictum sit, altum sonatur.
- Next message: dmorris_at_cup.hp.com: "Re: Memory Management HP-UX 10.20"
- Previous message: Dave Steele: "Oracle 7.3.4 and HP-UX 11i PA-RISC"
- In reply to: Manish Baronia: "Re: Finding kernel memory starting address on HPUX 11.0"
- Next in thread: Manish Baronia: "Re: Finding kernel memory starting address on HPUX 11.0"
- Reply: Manish Baronia: "Re: Finding kernel memory starting address on HPUX 11.0"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
