Announcement

Collapse
No announcement yet.

Way-Cooler Is Still Around As An i3-Inspired Wayland Compositor Written In Rust

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by oldgaro View Post

    Lastest firefox update (10 min ago) just used 7GB of "virtual memory" with one YT tab, reddit and feedly open ...and know what? frozen my laptop...haha

    Cute virtual memory...
    Whatever froze your laptop it's your problem, not Firefox's. Mine doesn't do that even with 70+ tabs open (my comics bookmarks)

    Comment


    • #32
      Originally posted by Zan Lynx View Post

      Whatever froze your laptop it's your problem, not Firefox's. Mine doesn't do that even with 70+ tabs open (my comics bookmarks)
      Newest firefox update is freezing with minimal tabs open. But that 7GB use of RAM was damn weird!

      Comment


      • #33
        Originally posted by tajjada View Post

        Wait ... can the 386 even address 4MB of memory? I thought it was far more limited than that. I am not too knowledgeable about the exact details of early x86 addressing modes, though. Maybe I am confusing it with the 286.
        The TL;DR for the link that you were given is:
        • Zilog Z80 and derivatives (eg. NES): 64k (Hence the profusion of bank-switching mapper chips used in cartridges which make writing cartridge dumpers a chore)
        • Intel 8086 and family: 1MiB address space (RAM + memory-mapped ROM)
        • 286 and 386SX: 16MiB
        • 386DX and all later 32-bit CPUs: 4GiB
        • Pentium Pro and Pentium 4: 36-bit addressing allowing 64GiB (still 4GiB limit per process) via special "PAE" memory-mapper instructions.
        • Modern CPUs: 64-bit virtual address space, but typically 48 addressing pins to save on transistors, resulting in a practical limit of 256TiB. Can be run in PAE mode to to expose up to 64GiB to a 32-bit OS at reduced efficiency.

        Comment


        • #34
          Originally posted by cybertraveler View Post

          Despite multiple efforts and lots of searching I still haven't figured out how to interpret the memory usage columns that htop provides.

          You have real physical memory. You have swap (disk backed) memory. You have virtual memory which represents both combined. Presumably the kernel can even provide memory beyond the sum of the physical and swap memory if it maps unused pages to a table of memory ranges used to record non-backed, unused virtual pages.

          You've also got memory pages shared between multiple apps. You've got memory that is considered part of the executable data and code regions. You've got stack and heap memory (are tools like top and htop even able to see the difference?).

          htop seems to show the same data for threads belonging to a process and the process itself. So I guess threads can't have their own memory. I don't know.

          You've also got shared libraries that that I guess use some type of shared memory which is probably shown in a virtual address space which may or may not be backed by physical memory, but is definitely used by multiple apps so can't be fairly considered to be part of the memory footprint of any individual app.

          There's probably copy-on-write, memory-saving shenanigans going on too which likely further skews the numbers.


          My current approach to managing my unending confusion in this matter is three fold:
          1. Put lots of physical memory in my machine.
          2. Try and use apps that claim to be lightweight when I don't need the heavy weight equivalents (eg use Transmission instead of Vuze for torrenting and Audacious instead of Rhythmbox for music).
          3. Pray daily to the silicon gods that they do not send their reaper to reap my processes. (They say his name is the OOM Killer and he acts without mercy and without consent)
          There are also specialized process-listing tools available which will attempt to account for shared components in various ways, such as dividing the size of shared libraries by the number of processes using them, though I don't remember any names off the top of my head.

          Comment


          • #35
            Originally posted by ssokolow View Post

            There are also specialized process-listing tools available which will attempt to account for shared components in various ways, such as dividing the size of shared libraries by the number of processes using them, though I don't remember any names off the top of my head.
            smem reports PSS (Proportional Set Size) and so does atop in the right display mode (display memory information with 'm', turn on PSIZE collection with 'R').

            Comment


            • #36
              Originally posted by ssokolow View Post

              The TL;DR for the link that you were given is:
              • Zilog Z80 and derivatives (eg. NES): 64k (Hence the profusion of bank-switching mapper chips used in cartridges which make writing cartridge dumpers a chore)
              • Intel 8086 and family: 1MiB address space (RAM + memory-mapped ROM)
              • 286 and 386SX: 16MiB
              • 386DX and all later 32-bit CPUs: 4GiB
              • Pentium Pro and Pentium 4: 36-bit addressing allowing 64GiB (still 4GiB limit per process) via special "PAE" memory-mapper instructions.
              • Modern CPUs: 64-bit virtual address space, but typically 48 addressing pins to save on transistors, resulting in a practical limit of 256TiB. Can be run in PAE mode to to expose up to 64GiB to a 32-bit OS at reduced efficiency.
              Thank you for the info. I learned some new things. I guess I was confused about the 386SX/386DX.

              Comment


              • #37
                Originally posted by oldgaro View Post

                Newest firefox update is freezing with minimal tabs open. But that 7GB use of RAM was damn weird!
                Virtual memory is *NOT* RAM usage. It often includes data from files and other things. It is the total amount of data that the process can access, regardless of whether it is in RAM, disk, hardware devices (VRAM on the gpu, peripherals, etc), or even not stored anywhere (generated by the kernel).

                Comment

                Working...
                X