virtual address space size of a proces - HP UX

This is a discussion on virtual address space size of a proces - HP UX ; guideveloper@gmail.com wrote: > How can i know that how much do i have for kernel space and how much > for user space in a process > Also if somebody can help me out with HP-UX 11 On HP-UX this ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: virtual address space size of a proces

  1. Re: virtual address space size of a proces

    guideveloper@gmail.com wrote:
    > How can i know that how much do i have for kernel space and how much
    > for user space in a process
    > Also if somebody can help me out with HP-UX 11



    On HP-UX this is hard because there is a shared global address space.
    That means any shared memory or mapped files (shlibs too) takes up space
    out of 4 Gb.
    For shared memory, you can track it with "ipcs -ma".

    Of course if these are allocated in the 64 bit space, they won't count.

  2. Re: virtual address space size of a proces

    On Nov 5, 6:47*pm, gordonb.er...@burditt.org (Gordon Burditt) wrote:
    > >I am looking to work on unix systems. I want to get the total virtual
    > >address space of a process, the used virtual memory of a process i am
    > >able to get without any problem. I have tried using getrlimit but that
    > >gives only *RLIMIT_INIFINITY or RLIMIT64_INFINITY if i use the
    > >getrlimit64.

    >
    > >Can you give me an idea on how much virtual addressable space is there
    > >in each respective unix system for a user address space as i need to
    > >do my memory allocations based on that and show a warning in an
    > >application when the memory is about to get depleted?

    >
    > UNIX is not a uni-tasking system. *It is going to be very difficult
    > to make several processes based on the GREED memory allocation
    > scheme (allocate everything I can before I know I'll need it)
    > cooperate with each other if they don't know how. *While it might
    > be possible to make two instances of the same program cooperate
    > with each other, it's not possible to do that with programs using
    > the same strategy that don't know about each other.
    >
    > How likely is it that someone will want to dedicate an entire machine
    > to running your program? *If it's a database I can see the point,
    > but usually for a database there are several dozen different things
    > that can be tuned for how much memory to use, and correctly allocating
    > the memory to the right pool is more important than grabbing all
    > the memory you can. *You're stuck with manual tuning from some kind
    > of configuration file or command line arguments. *The admin might
    > want to allow enough space for backup programs to run (there *IS*
    > data other than the database that needs backing up) without shutting
    > down your application (it might be much easier to just shut down
    > processing of queries than terminating and restarting the process).
    >
    > There are several limits to the virtual memory that can be allocated
    > by a user process. *You're stuck with the lowest one:
    >
    > 1. *Limits on the address space: *2**number_of_bits_in_a_pointer.
    > This may be lower if there are bits for privilege levels or other
    > such things in a pointer. *That's 4GB for a 32-bit system. *This is
    > pretty much fixed for a given system.
    >
    > 2. *The kernel may take a chunk out of the address space in #1 for
    > itself. *You might be limited to 2GB or 3GB on a 32-bit system.
    > This is pretty much fixed for a given system.
    >
    > 3. *Limits on backing store: *The size of RAM + the size of swap/page
    > space minus what everyone (including the process itself) has
    > allocated. *It's possible the admin could add swap space to a running
    > system, but it's an unusual procedure. *The amount of RAM and
    > swap/page space is individual to every system, although there are
    > guidelines. *The totals of what everyone has allocated is *extremely*
    > volatile as processes are created, allocate memory, and terminate.
    >
    > 4. *Administrative limits on virtual memory: *you could probably
    > see these with getrlimit(). *The limit might be changable somewhat
    > with setrlimit(), especially downward. *It won't normally change
    > without the program knowing about it during a given run.
    >
    > 5. *Policies to avoid deadlock might prevent a process from allocating
    > more than a certain percentage of RAM + swap/page space.
    >
    > 6. *The amount of memory you can allocate without non-zero risk of
    > the Linux OOM killer killing your process or some process that you
    > require to function (e.g. syslog, nameserver, NFS daemon, mountd,
    > etc.) is about what you've already got plus ZERO. *No, that doesn't
    > actually reduce the risk to zero, especially if there's another process
    > around using the GREED memory allocation strategy.
    >
    > There is a good possibility that the GREED memory allocation strategy,
    > especially if it's very accurately tuned, will have the process
    > getting in its own way. *For example, it might accurately grab
    > exactly all the memory it can get, but not take into account that
    > the system library needs memory for something the program will use
    > later: stdio file buffers, name resolution, mapping in another
    > shared library on the fly, etc. *There's no point in warning the
    > user to reduce memory at this point: *if the message can even be
    > sent to the user without running out of memory first, there may be
    > nothing for the user to kill off that lets the process continue.
    >
    > There's also the possibility that allocating memory before you
    > determine that you need it kills performance because of an increased
    > amount of swapping. *It might actually finish. *Slowly.


    Hi all,

    I understand the complete picture now. Thanks a lot guys especially
    Gordon, Casper and Nate.

    Still if somebody can help me with how to programatically access
    kernel parameters mentioned below in a user program that would be of
    real great help!

    maxdsiz for HP-UX
    USERLIMIT and KERNELBASE for sun solaris >= 2.6

    Cheers,
    R

  3. Re: virtual address space size of a proces

    guideveloper@gmail.com wrote:
    >
    > Still if somebody can help me with how to programatically access
    > kernel parameters mentioned below in a user program that would be of
    > real great help!
    >
    > maxdsiz for HP-UX


    You can query this on 11i v1 (11.11) and later using the gettune()
    system call [man 2 gettune] though I wouldn't. getrlimit for RLIMIT_DATA
    and checking the hard and soft limits is much more to the point.
    If no ancestor of your process (like say, your shell) lowered your
    hard limit, your hard limit will be maxdsiz [since that's what maxdsiz
    *does*]. And if they did -- that lowered hard limit is more relevant
    to your process than maxdsiz anyway. (Plus, when you go to v2 and beyond
    where maxdsiz is dynamic -- your process should only worry about what
    maxdsiz was when it started [since changes to maxdsiz don't affect
    current processes only new ones]... which means again, getrlimit()
    is what you want to look at).

    Don
    --
    kernel, n:
    A part of an operating system that preserves the medieval traditions
    of sorcery and black art.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2