Re: Mach VM management question
Re: Mach VM management question
- Subject: Re: Mach VM management question
- From: Jim Magee <email@hidden>
- Date: Mon, 29 Jul 2002 12:09:11 -0400
On Saturday, July 27, 2002, at 06:51 AM, Pejvan BEIGUI wrote:
Hi guys,
I have a question regarding the VM management in Mach/Darwin.
Since I don't like to reboot my mac, and since I use a lot of different
applications, not at the same time, I'm surprised to see that the VM
storage
on my drives keeps going up, and never fall down.
I have a tibook 500MHz, with 512MB of RAM, so I don't think that it's
normal
to have so many VM used at the same time on my machine :
...[list of swap files deleted]...
So, is there a way to tell the system to update the VM ? Or tell him to
remove the unused VM swapfiles ?
It happens automatically as the space is released. But this is
controlled by a user-level daemon process (dynamic_pager). If that
got killed off somehow, you would neither free up any unused ones or
allocate any new ones. While I've never seen that happen, its
something to look for in extremely weird cases.
Plus here's the output of my top :
Processes: 55 total, 2 running, 1 stuck, 52 sleeping... 159 threads
12:44:56
Load Avg: 0.73, 1.49, 1.34 CPU usage: 8.3% user, 17.4% sys,
74.4% idle
SharedLibs: num = 126, resident = 15.3M code, 564K data, 3.75M
LinkEdit
MemRegions: num = 8314, resident = 163M + 4.56M private, 46.9M shared
PhysMem: 59.6M wired, 283M active, 164M inactive, 506M used,
6.21M free
VM: 1.69G + 56.4M 253129(0) pageins, 597340(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE
VSIZE
5852 top 15.7% 0:00.78 1 14 17 424K 296K 680K
1.70M
328 Terminal 1.6% 21:56.01 7 131 877 3.04M 7.81M 7.14M
67.0M
333 MicrosoftK 1.6% 2:11.97 1 53 50 220K 1.12M 308K
38.7M
5583 Proteus 0.8% 27:28.55 5 139 707 58.7M 5.92M 60.2M
181M
5584 imservices 0.8% 4:18.92 4 32 506 49.6M+ 804K 49.3M+
108M
5594 imserviced 0.8% 1:26.12 1 22 34 1.24M 768K 1.84M
4.74M
73 Window Man 0.0% 3:43:16 3 2527 3192 3.65M 26.2M 29.6M
116M
0 kernel_tas 0.0% 92:30.52 26 0 - - - 47.7M
400M
327 SystemUISe 0.0% 16:15.06 4 138 237 1.83M 4.10M 2.59M
60.9M
289 java 0.0% 16:13.80 26 205 181 2.85M 260K 2.33M
171M
133 configd 0.0% 13:52.09 4 108 173 456K 632K 768K
4.29M
2431 Dock 0.0% 3:28.85 3 106 195 1.32M 5.12M 2.58M
56.1M
330 MicrosoftM 0.0% 3:15.36 1 77 37 184K 552K 288K
26.1M
3323 Microsoft 0.0% 2:08.50 2 75 141 2.79M 6.58M 3.12M
58.3M
So what is this kernel_tasks using 400M VSize ?
The kernel allocates some virtual address space (space in submaps, not
actual memory) for efficient future memory allocation and wiring later
on. Top picks that up and reports it. Kernel leaks would most likely
cause a rise in wired memory. With 512MB of memory, the 59.6MB of
wired memory is not a major concern (some wired data structure counts
scale up with amount of physical memory).
There are uses of true virtual (pageable) memory within the kernel.
Specifically, some of the (not currently in-use) texture maps for
graphics acceleration are stored in kernel pageable memory. And some
(sent, but not-yet-received) Mach IPC data is stored in pagable kernel
memory.
There is no way to distinguish between over-commit virtual address
space allocations in the kernel, and true pageable memory allocations
using top. So we can't tell how much of that 400MB of kernel virtual
falls into each of the two categories above. In fact, it isn't
possible to tell that for any other task/process either. Since your
maximum "dirty virtual" memory size of ~1GB (7*76MB swap files + 512MB
of physical memory) is less than the 1.69GB of all virtual allocations
reported by top (even when you remove the 400MB of potentially unused
space in the kernel), it may be correct.
Your top says there are 55 processes, and you only show 14 of them. Is
there anything else of interest in those other 41 processes?
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.