Huge virtual memory size in 64-bit Mac OS X 10.7.4?

Hello.

I noticed my Terminal's top command shows virtual memory really big like
about 200 GB. I tried rebooting the updated 64-bit Mac OS X 10.7.4, but
it is still big like shown in http://pastie.org/4379346 (wide screen
recommended) even if I don't have anything running (e.g., VMware Fusion
v7.1.4) except the background startups, Terminal, and top command.

Is this normal? Does it really need a huge virtual memory size? This is
on a month old Mac Mini (late 2011 model) with 4 GB of RAM.

Thank you in advance.
--
Quote of the Week: "Ants die in sugar." --Malawi
/\___/\ Ant(Dude) @ http://antfarm.home.dhs.org (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / Please nuke ANT if replying by e-mail. If crediting,
( ) then please kindly use Ant nickname and AQFL URL/link.

(Ant) writes:
> I noticed my Terminal's top command shows virtual memory really big like
> about 200 GB. I tried rebooting the updated 64-bit Mac OS X 10.7.4, but
> it is still big like shown in http://pastie.org/4379346 (wide screen
> recommended) even if I don't have anything running (e.g., VMware Fusion
> v7.1.4) except the background startups, Terminal, and top command.
>
> Is this normal? Does it really need a huge virtual memory size? This is
> on a month old Mac Mini (late 2011 model) with 4 GB of RAM.
>
> Thank you in advance.

VSIZE over the whole system doesn't really measure an exhaustible
resource. Within one process it reflects address space usage, which is
comparatively easy to run out of for a 32-bit process, but rather hard
to do for a 64-bit process.

Still, the VSIZE figure reported per process does show some curious
inconsistencies. For instance this process is supposedly using well
over 2GB of address space:

$ ps -o pid,comm,rss,vsize -p 7110
PID COMM RSS VSZ
7110 -bash 832 2435492

Yet adding up its memory mappings yields only about 5% of that figure:

$ vmmap 7110 |perl -ne '/([0-9a-f]{16})-([0-9a-f]{16})/ && ($tot += hex($2)-hex($1)); END { print $tot/1024,"\n"; }'
127744

Possibly vmmap is hiding mappings that support none of read, write or
execute. These can amount to a lot - for instance on a 64-bit Linux
system there is a 2MB PROT_NONE mapping for every shared library used by
a process, potentially hugely inflating the reported VSIZE.

--
http://www.greenend.org.uk/rjk/

In article
<chine.bleu->,
"China Blue [Tor], Meersburg" <> wrote:

> I suppose at some point 64-bit addresses space will seem as crowded as 32-bit
> spaces are now, but that might not occur until the Y10K problem rears up.

That's the kind of thing they said about 32-bit spaces in the late '70s.
Just wait 20 years.

--
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

In message <howard->
Howard S Shubs <> wrote:
> In article
> <chine.bleu->,
> "China Blue [Tor], Meersburg" <> wrote:

>> I suppose at some point 64-bit addresses space will seem as crowded as 32-bit
>> spaces are now, but that might not occur until the Y10K problem rears up.

> That's the kind of thing they said about 32-bit spaces in the late '70s.
> Just wait 20 years.

64 bit spaces are not simply twice as bit as 32 bit spaces.

32 bit space is 4,294,967,296 bits.

64 bit spaces is 1.84467e19 bits. (that's 18 followed by 18 zeros, give
or take)

if we double it again to 128 bits, the energy needed to toggle ever
location in 128bit address space is more energy than it would take to
boil all the oceans of the Earth.


--
I WILL NOT INSTIGATE REVOLUTION Bart chalkboard Ep. 7G06

In article <EvGdnSymBpxST4fNnZ2dnUVZ_u->,
(Ant) wrote:

> Hello.
>
> I noticed my Terminal's top command shows virtual memory really big like
> about 200 GB. I tried rebooting the updated 64-bit Mac OS X 10.7.4, but
> it is still big like shown in http://pastie.org/4379346 (wide screen
> recommended) even if I don't have anything running (e.g., VMware Fusion
> v7.1.4) except the background startups, Terminal, and top command.
>
> Is this normal? Does it really need a huge virtual memory size? This is
> on a month old Mac Mini (late 2011 model) with 4 GB of RAM.
>
> Thank you in advance.

vsize is how many CPU addresses are valid so it doesn't mean much. The
addresses may map to swap, files, libraries, I/O, virtual devices, guard
spaces, RAM, or other stuff.

Run 'top -S' to show swap used.
--
I will not see posts from Google because I must filter them as spam

Better yet: install MenuMeters, an open-source
memory/temperature/bandwidth monitor that shows exactly how large the
swap file is.

http://www.ragingmenace.com/software...ers/index.html

It works with Mountain Lion.

On 2012-08-05 00:25:58 +0000, Kevin McMurtrie said:

> In article <EvGdnSymBpxST4fNnZ2dnUVZ_u->,
> (Ant) wrote:
>
>> Hello.
>>
>> I noticed my Terminal's top command shows virtual memory really big like
>> about 200 GB. I tried rebooting the updated 64-bit Mac OS X 10.7.4, but
>> it is still big like shown in http://pastie.org/4379346 (wide screen
>> recommended) even if I don't have anything running (e.g., VMware Fusion
>> v7.1.4) except the background startups, Terminal, and top command.
>>
>> Is this normal? Does it really need a huge virtual memory size? This is
>> on a month old Mac Mini (late 2011 model) with 4 GB of RAM.
>>
>> Thank you in advance.
>
> vsize is how many CPU addresses are valid so it doesn't mean much. The
> addresses may map to swap, files, libraries, I/O, virtual devices, guard
> spaces, RAM, or other stuff.
>
> Run 'top -S' to show swap used.

--
Blah blah bleh...

GCS/CM d(-)@>-- s+:- !a C++$ UBL++++$ L+$ W+++$ w M++ Y++ b++

On 2012-08-03 06:28 , Lewis wrote:
> In message <howard->
> Howard S Shubs <> wrote:
>> In article
>> <chine.bleu->,
>> "China Blue [Tor], Meersburg" <> wrote:
>
>>> I suppose at some point 64-bit addresses space will seem as crowded as 32-bit
>>> spaces are now, but that might not occur until the Y10K problem rears up.
>
>> That's the kind of thing they said about 32-bit spaces in the late '70s.
>> Just wait 20 years.
>
> 64 bit spaces are not simply twice as bit as 32 bit spaces.
>
> 32 bit space is 4,294,967,296 bits.

That's that many addresses, not bits. If it is a byte sized memory
scheme (most) then multiply that number by 8 (to get the number of bits
addressed).

An "address" may refer to a location containing a bit, or 8 or any
number of bits or bytes.

Typically (these days) it will address 1 byte while allowing a single
fetch cycle (2 clocks usually) loading of 1, 2, 4 or 8 bytes (depending
on the databus width of course, 8 bytes corresponding to a 64 bit wide
databus - which is not a necessity for 64 addressing).

The 'mechanics' of it are handled in CPU hardware of course, but imagine
wanting to load a single byte from address 13 with a 64 bit wide
databus. The actual address loaded from would be 8 and would include
all the bytes from 8 to 15. The 8 bits at address 13 would then be
loaded into the register of interest. (because of this assemblers and
compilers usually have a mode to assure location assignments beginning
on 'even' address bounds according the to bus width and data size,
resulting in a lot of unused static memory - though optimization can
'fill' most of the dead spots). I digress.

This could be any width the designer chooses but there's a point at
which it no longer pays. Some GPU's load 16 bytes (128 bits) per load
instruction. (whether these are instructions or data is immaterial -
thus each cycle could load 1 or many instructions including partial
instructions (CISC esp.) that will take another cycle to fetch the
remainder of that instruction. (Even a data fetch of 1 byte will result
in a fetch of the databus width, though this is not esp. easy to exploit
for efficiency. I digress).

> 64 bit spaces is 1.84467e19 bits. (that's 18 followed by 18 zeros, give
> or take)

Still wrong and bad arithmetic to boot.

And the real point of course is not about addressing physical memory but
in the partitioning of virtual memory spaces as required. I'm sure you
can find a reference somewhere.

> if we double it again to 128 bits, the energy needed to toggle ever
> location in 128bit address space is more energy than it would take to
> boil all the oceans of the Earth.

That you have right at least.

--
"Civilization is the limitless multiplication of unnecessary necessities."
-Samuel Clemens.