Thus spake Matthew Dillon <[EMAIL PROTECTED]>: > :Thanks for the explanations! I still don't understand why this > :doesn't work, assuming you don't care about nonresident pages: > : > :for each process p in the set > : for each map entry e in p->vmspace->vm_map > : for each page m in e->object.vm_object->memq > : if I haven't seen this m.phys_addr yet in the scan > : resident_pages++ > > That would get close, as long as the machine is not paging heavily. > Think of it this way: If you have a lot of ram the above calculation > will give you an upper bound on memory use, but some of the pages > in the VM object's may be very old and not actually under active > access by the process (for example, the pages might represent part > of the program that was used during initialization and then never used > again). If you do not have so much memory older pages will get flushed > out or flushed to swap and the above calculation will represent more > of a lower bound on the memory used by the group of processes.
Yes, I understand this; that's why I said ``assuming you don't care about nonresident pages'' (a pretty big assumption, mind you.) I was just thinking about essentially calculating the physical memory usage for a set of processes, taking sharing into account, and I take it you were talking about calculating the total amount mapped. I imagine both metrics would be useful. For instance, a database might map a huge file but have a very small resident set. I don't know what the OP intended... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
