Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Limit on the system-wide address space in Unix ..

Posted on 1999-06-22
Medium Priority
Last Modified: 2010-04-21
On 32-bit systems, processes are allowed to have upto a maximum of 2^32 bytes of address space ...Assume that process A is consuming this entire range of address space (4GB) ...My question is :

1. Is there any limit on the number of processes similar to Process A? On a 32 bit system, can we have as many process as we want each consuming 4GB of address space SIMULTANEOUSLY ? (consider for now that there is lots and lots of paging space and swapping/performance is not an issue ..)

2. If there is a limit (OS related), why is that limit due to?
Question by:srivatsa_v
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2

Author Comment

ID: 2011129
Edited text of question.

Author Comment

ID: 2011130
Edited text of question.
LVL 51

Expert Comment

ID: 2011131
1. Yes and no.
   you may have as much such process as the kernel allows, either up to max number of processes at all, or max number of processes per user.
2. the limit is either in the kernel and/or in the shell, see ulimit and/or limits command (deoending on your shell)
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 2011132
I am considering a hypothetical 32-bit system where there is no crunch for RAM and paging space (not really, but assume that these are not limiting factors)....

1. In theory atleast, on such a system, can we have as many processes as we want each of 4GB size? Assume the bulk of the kernel is pageable (process table etc. )

2. If there is some limitation on the number of such processes, what are the limiting factors (apart from performance issues) ...


Author Comment

ID: 2011133
Also pls assume that there are no per-user OR system-wide soft/hard limits ...
LVL 14

Accepted Solution

chris_calabrese earned 400 total points
ID: 2011134
The only theoretical limit I can think of is that the kernel can't grow bigger than 4gig.  Since each process has kernel memory for file table entries, process table entries, paging table entries, etc, etc. there will be an upper bound.

Also, there may be hardware limits on the total page table sizes due to the structures used to hold them.
LVL 51

Expert Comment

ID: 2011135
beside chris_calabrese's answer, the limit is as follows:

  the physical memory ($GB in your example) must contain:
    1. the code for paging, the code for task scheduling, and probably some other
    2. tables for paging
    3. tables for processes
    4. area to for the current task (one of the processes which is to be run in the time slice)

So if we asume 1. and 4. as a fixed size, 3. probably too as fixed size, then the number of processes depends on the size remaining for 2.

Is this the theoretical thing you're looking for?
LVL 14

Expert Comment

ID: 2011136
I don't think any of these should present a limit to the number of processes with 4gb address space other than that they contribute to the total kernel memory used (all these things have to be in the kernel address space so the kernel can diddle with them - well, assuming it's not a microkernel that has a user-space process that handles the paging, but that doesn't change things all that much in the end).

They do, however, limit the amount of real memory a process might be able to use (i.e., it can't actually get all the real memory of the system because some of it's in use).

As far as the question of how much real memory might be used, the bare theoretical minimum is:
  1.  Code for paging.
  2.  Code for interrupt handling.
  3.  Interrupt vectors.
  4.  Pointer to kernel page table.
  5.  Pointer to page tables for tasks currently running (max of number of processors).
  6.  Code for handling switch from user space to kernel space.

The other things like the actual page tables and code for task switching can be paged in.  Yes, this is _really_ minimal and most real OS' keep a lot more kernel stuff nailed down in memory for performance reasons.  However, most modern hardware will let you do things this way if you wish.
LVL 51

Expert Comment

ID: 2011137
.. I forgot the interrupt stuff, true.

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Java performance on Solaris - Managing CPUs There are various resource controls in operating system which directly/indirectly influence the performance of application. one of the most important resource controls is "CPU".   In a multithreaded…
Why Shell Scripting? Shell scripting is a powerful method of accessing UNIX systems and it is very flexible. Shell scripts are required when we want to execute a sequence of commands in Unix flavored operating systems. “Shell” is the command line i…
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.

661 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question