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

Discussion in 'Apple' started by Ant, Aug 2, 2012.

  1. Ant

    Ant Guest

    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, Aug 2, 2012
    #1
    1. Advertising

  2. (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/
     
    Richard Kettlewell, Aug 2, 2012
    #2
    1. Advertising

  3. In article
    <-september.org>,
    "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
     
    Howard S Shubs, Aug 3, 2012
    #3
  4. Ant

    Lewis Guest

    In message <>
    Howard S Shubs <> wrote:
    > In article
    > <-september.org>,
    > "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
     
    Lewis, Aug 3, 2012
    #4
  5. In article <>,
    (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
     
    Kevin McMurtrie, Aug 5, 2012
    #5
  6. Ant

    Salvatore Guest

    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/menumeters/index.html

    It works with Mountain Lion.

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

    > In article <>,
    > (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++
     
    Salvatore, Aug 5, 2012
    #6
  7. Ant

    Alan Browne Guest

    On 2012-08-03 06:28 , Lewis wrote:
    > In message <>
    > Howard S Shubs <> wrote:
    >> In article
    >> <-september.org>,
    >> "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.
     
    Alan Browne, Aug 5, 2012
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arunaabh
    Replies:
    4
    Views:
    566
    Yousuf Khan
    May 6, 2006
  2. Monica

    Virtual Memory Size

    Monica, Oct 2, 2006, in forum: Dell
    Replies:
    1
    Views:
    323
    Tom Scales
    Oct 3, 2006
  3. esquivel_rene
    Replies:
    0
    Views:
    476
    esquivel_rene
    Jan 5, 2004
  4. Paul Tilling

    Huge Virtual Memory size with OsX.4.9

    Paul Tilling, May 16, 2007, in forum: Apple
    Replies:
    3
    Views:
    190
    matt neuburg
    May 17, 2007
  5. David
    Replies:
    4
    Views:
    278
    Kevin McMurtrie
    Jul 20, 2009
Loading...

Share This Page