Chris Angelico writes: > Both processes are using the virtual memory. Either or both could be > using physical memory. Assuming they haven't written to the pages > (which is the case with executables - the system mmaps the binary into > your memory space as read-only), and assuming that those pages are > backed by physical memory, which process is using that memory?
One doesn't know. Clever side-channel attacks aside, I don't care, and I don't see how it could matter. > > > Tell me, which process is responsible for libc being in memory? > > > Other than, like, all of them? > > > > Yes. Why would you want a different answer? > > Because that would mean that I have way more *physical* memory in use > than I actually have chips on the motherboard for. No, that's like saying that because you have multiple links to a file on disk you're using more physical disk than you have. > Yes, virtual memory can be over-allocated, but physical memory > can't. How do you measure where your physical memory is being used, > if adding up the usage of all processes exceeds the available > resources? lsof can do it, I guess. The kernel knows which pages of which processes' virtual memory are backed by physical memory. But just as running over the array of inodes tells you how much physical disk is allocated, without looking at directories to find out what it's allocated to, the kernel probably has a bitmap or similar so it knows which pages of physical memory are in use. All problems are easy once you have enough indirection. :^) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
