Home > Archive > Unix Programming > September 2006 > how to get virtual address space
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to get virtual address space
|
|
| Subhash 2006-09-11, 4:01 am |
|
Hi all,
I am using Linux 2.4.* kernel.
I would like to know how much virtual address space my system
have.
is there any way to get it from /proc/meminfo.
Regards/-
Subhash..
| |
| Paul Pluzhnikov 2006-09-11, 4:01 am |
| "Subhash" <msubhashreddy@gmail.com> writes:
> I would like to know how much virtual address space my system have.
Simple:
size_t getVirtualAddressSpace()
{
return ~((size_t)0);
}
This answers 0xFFFFFFFF on 32-bit systems, and 0xFFFFFFFFFFFFFFFF
on 64-bit ones.
Now, perhaps you want to ask the question you *really* need an
answer for?
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Lew Pitcher 2006-09-11, 8:01 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Subhash wrote:
> Hi all,
> I am using Linux 2.4.* kernel.
> I would like to know how much virtual address space my system
> have.
You are going to have to be clearer about what it is that you want.
You ask for "how much virtual address space", but you don't say /which/
virtual address space you are interested in. You see, there's a unique
virtual address space for each process running on your system, and you
likely have /many/ processes running at any one time. This means that
you have /many/ virtual address spaces, all different, available at any
one time, and there's no way we can tell which virtual address space
you are interested in.
You might even be interested in the "aggregate sum of the size of all
the current virtual address spaces" (which /might/ be related to how
big your swap+ram must be), or perhaps the "theoretical maximum size of
a virtual address space" (which /might/ be related to the largest
memory footprint a single process can reach), but we can't tell from
your question.
Would you care to rephrase your question to tell us what it is you are
actually interested in, and why?
> is there any way to get it from /proc/meminfo.
It depends on what it is you are looking for, I guess.
> Regards/-
> Subhash..
HTH
- --
Lew Pitcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12
iD8DBQFFBVwtagVFX4UWr64RAsXIAJ9nDEeWqzsh
+CzyTwLcraM11aSEHACg5+UE
HpJGb3AzLDd/Aaf6t3mZGnI=
=f3N5
-----END PGP SIGNATURE-----
| |
| Subhash 2006-09-12, 4:00 am |
|
Lew Pitcher wrote:[color=darkred]
>
> Would you care to rephrase your question to tell us what it is you are
> actually interested in, and why?
>
i mean /proc/meminfo contain some information about memory
but there is no information about the total Virtual space currently
using..
can u tell what exactly "Virtual address space" means...
Thanks
Subhash...
| |
| Lew Pitcher 2006-09-12, 8:03 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Subhash wrote:
> Lew Pitcher wrote:
>
> i mean /proc/meminfo contain some information about memory
> but there is no information about the total Virtual space currently
> using..
Should there be? Is it a meaningful number? In any case, you are wrong.
The information is there, if you know what to look for.
> can u tell what exactly "Virtual address space" means...
OK, I'm not a teacher, and this isn't "Operating Systems 101", but I'll
give it a try.
- From the point of view of a running process, it occupies memory in
such a manner that all its code and data are directly addressable by
the program. The range of addresses that a program can use to access
itself is known as it's "address space".
In the simplest form of computing environment (think MSDOS, for
instance), the process "lives" in real memory. Every part of real
memory has a unique address, and the process can reach all parts of
real memory.
However, in modern computing environments, the OS works behind the
scenes to move pieces of each process into and out of memory as it
needs. So, at any moment, while instructions for a single process are
running, only those portions of memory that the OS has given to the
process are accessable to the process. In fact, if the process tries to
address data outside of those regions, the OS will intercept the
access, suspend the process, and move program code around (out of and
into memory) to position the accessed into memory. The "real" address
of the data is not likely to be the same as the address the process
asked for - it is up to the OS to map these addresses together.
This technique lets each process think that it has the entire real
memory to itself, while it actually only has bits and pieces of memory,
and the rest is used by other processes. The "view from the inside" of
each process shows a contigious memory map, with all parts accessable",
the view from outside shows a patchwork of memory and disk space
scattered about.
Since each process /thinks/ that it has a full range of memory (an
"address space", remember), but the OS (and we) know that this is an
illusion, the range of addresses a process can reach is known to live
in its "virtual address space".
There is one, independant, virtual address space for each process.
Processes don't share virtual address spaces.
A virtual address space can be larger than the memory that the process
uses. A process that is only 4K big still lives in an address space (a
range of addresses) that is much larger. There is no fixed relationship
between the sum of all current virtual address spaces and the amount of
memory (real or swap) being used at any one time.
Virtual address spaces are created and destroyed as processes are
launched and terminated. There is no fixed upper limit to number of
virtual address spaces /in relation to real memory/.
HTH
- --
Lew Pitcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12
iD8DBQFFBqwUagVFX4UWr64RAlgpAKDWCzT+ow0N
5wqIINZCa97JSuLKIACgvYEL
FMPKPoI7QNcSKRdbSjaJASE=
=to0u
-----END PGP SIGNATURE-----
|
|
|
|
|