Hi All,
I want to know the starting address of kernel memory on a HPUX11
machine. I got a C program which is built for LINUX OS, which can find
starting kernel address by this algo:

It starts from the address of argc (in main function) and keeps
incrementing this address and accessing content of this address, until
there is a SEG fault.
The address at which this SEG fault comes, is the starting address of
kernel.

The program is something like this:
main (int argc, char **argv) {
char *p;
char c;
for (p=&argc; p; p++) {
c = *p;
}
}
The value of p, at which seg fault comes, is the starting adress for
kernel area of memory.
This solution has two strong assumptions:
- the VM is divided into 2 contiguous parts: one for the user space, and
one
for the kernel space.
- the kernel starts right 'after' the process stack.

Now I want to port same on HP and solaris systems. Can someone tell me
if the assumptions written above work good for these two systems also.
Or, if there are some other ways in C to find kernel starting memory
address.

Thanks,
Manish

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...

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

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.

dmorris@cup.hp.com wrote:

> 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.

Hello Don,
> 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).

My application uses malloc and mmap (Shared) both, so it can grow in private
and shared area both. So, on a normally compiled 32-bit PA-RISC, can my
application
not grow more than 2GB? (1GB for DATA and 1GB for mmap?)

If kernel options are changed and recompiled, can my application grow 4GB
(assuming text
and stack sizes are very minimal and DATA and SHARED memory sizes are ~2GB)?
Thanks,
Manish

Manish Baronia <manishbaronia@hotmail.com> wrote:
> dmorris@cup.hp.com wrote:

<big kersnip>

> Hello Don,
> > 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).

> My application uses malloc and mmap (Shared) both, so it can grow in private
> and shared area both. So, on a normally compiled 32-bit PA-RISC, can my
> application
> not grow more than 2GB? (1GB for DATA and 1GB for mmap?)

Your application, if compiled with the defaults and not chatr'ed,
i.e. 32-bit PA-RISC EXEC_MAGIC can get up to 1Gb of private space
(which is divided among BSS, Heap, stack and private MMF -- so
you'll never actually *get* 1Gb through malloc. You do need a
stack, at the least).

It can use up to 1.75Gb of shared space assuming no other process
is using any shared objects other than the ones your process is
using (this is Globally Shared space). That's rather unlikely,
so you usually get less.

> If kernel options are changed and recompiled, can my application grow 4GB
> (assuming text
> and stack sizes are very minimal and DATA and SHARED memory sizes are ~2GB)?
> Thanks,
> Manish

If you use the (normal) globally shared q4, you'll only be able
to approach 3.75Gb because the last .25Gb is reserved for memory
mapped I/O and there's nothing that will change that. Also, as mentioned
above - the odds of *nothing* else on the system using any shared
memory at the same time is pretty low. If you really, really want
to try to get as close as you can - you have to use either Memory
Windows or set the third and fourth quadrants private using chatr.

Oh -- and don't forget that you have to have swap to back this up.
Otherwise it won't matter how much address space you have left, you'll
fail the allocation.

Don
--
Quidquid latine dictum sit, altum sonatur.

dmorris@cup.hp.com wrote:
> Manish Baronia <manishbaronia@hotmail.com> wrote:
>> dmorris@cup.hp.com wrote:

> <big kersnip>

>> Hello Don,
>> > 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).

>> My application uses malloc and mmap (Shared) both, so it can grow in private
>> and shared area both. So, on a normally compiled 32-bit PA-RISC, can my
>> application
>> not grow more than 2GB? (1GB for DATA and 1GB for mmap?)

> Your application, if compiled with the defaults and not chatr'ed,
> i.e. 32-bit PA-RISC EXEC_MAGIC can get up to 1Gb of private space

How embarassing. I meant SHARE_MAGIC in the above line. EXEC_MAGIC
will get you ~2Gb of private space.

Don

> (which is divided among BSS, Heap, stack and private MMF -- so
> you'll never actually *get* 1Gb through malloc. You do need a
> stack, at the least).

> It can use up to 1.75Gb of shared space assuming no other process
> is using any shared objects other than the ones your process is
> using (this is Globally Shared space). That's rather unlikely,
> so you usually get less.

>> If kernel options are changed and recompiled, can my application grow 4GB
>> (assuming text
>> and stack sizes are very minimal and DATA and SHARED memory sizes are ~2GB)?
>> Thanks,
>> Manish

> If you use the (normal) globally shared q4, you'll only be able
> to approach 3.75Gb because the last .25Gb is reserved for memory
> mapped I/O and there's nothing that will change that. Also, as mentioned
> above - the odds of *nothing* else on the system using any shared
> memory at the same time is pretty low. If you really, really want
> to try to get as close as you can - you have to use either Memory
> Windows or set the third and fourth quadrants private using chatr.

> Oh -- and don't forget that you have to have swap to back this up.
> Otherwise it won't matter how much address space you have left, you'll
> fail the allocation.

> Don
> --
> Quidquid latine dictum sit, altum sonatur.

--
Quidquid latine dictum sit, altum sonatur.