Memory cvars

From WolfWiki
Jump to: navigation, search

Determining memory usage


s_list will display a list of all sounds and whether they're currently in RAM, along with a summary at the end, e.g.:

0[16bit] : sound/weapons/mortar/mortarf1.wav[paged out]
53950[16bit] : sound/etpro/osp_fight.wav[resident ]
52808[16bit] : sound/etpro/osp_goat.wav[resident ]
Total resident: 45634975

105060 bytes (0.10MB) free sound buffer memory, 50521500 bytes (48.18MB) total used
92463100 bytes (88.18MB) sound buffer memory have been allocated since the last SND_setup

This example is with com_soundmegs 48, and it shows that if I wanted to keep all the sound in memory, I'd want to shoot for soundmegs 96 or so. In reality, that's probably overkill (some large sounds, like the per-level voiceover in the limbo menu, are rarely used), but I'm pretty sure they're all loaded when you load the level, regardless (and just freed again if you use up soundmegs.) So, basically, a high-ish soundmegs is good, but setting it really high probably won't help much unless you have a really slow/busy disk but a lot of RAM.

Note that sample rate affects sound memory needs (s_khz 44 will use twice as much memory as 22, which in turn uses twice as much as 11).

Hunk and Zone

meminfo will display information about the hunk and the zone:

67108864 bytes ( 64.00 MB) total hunk <- current com_hunkMegs
25165824 bytes ( 24.00 MB) total zone <- current com_zoneMegs

       0 bytes (  0.00 MB) low mark
42606880 bytes ( 40.63 MB) low permanent
 5864568 bytes (  5.59 MB) low tempHighwater <- top low hunk usage from temporary allocations

       0 bytes (  0.00 MB) high mark
     384 bytes (  0.00 MB) high permanent
   82624 bytes (  0.08 MB) high temp
18769504 bytes ( 17.90 MB) high tempHighwater <- top high hunk usage from temporary allocations

42607264 bytes ( 40.63 MB) total hunk in use <- current hunk in use
18769120 bytes ( 17.90 MB) unused highwater <- temporary hunk memory that wasn't reused

 2055832 bytes (  1.96 MB) in 3088 zone blocks <- current zone usage
               0 bytes (  0.00 MB) in dynamic botlib
         1110492 bytes (  1.06 MB) in dynamic renderer
          945340 bytes (  0.90 MB) in dynamic other
           82888 bytes (  0.08 MB) in small Zone memory

(note the comments to the right of each line) So, the client uses a fair bit of hunk memory (adding together the total hunk and the unused highwater, my com_hunkmegs of 64 looks pretty good), a lot of sound memory, and very little zone memory.

The value of com_zonemegs can only be set via commandline (+set com_zonemegs xx). If set in the config, the desired value will only show as "latched." Regardless, meminfo always lists zone as 24 (the default), which would imply that this value cannot be changed.