Sorry, I think the short answer will be that you should give up on this:
reasons below.
Yes.
You would have to add a function in mm/shmem.c to do this: it would
need to check vma->vm_file to work out if this vma belongs to it,
and use shmem_swp_alloc() to check if the page there is on swap. OTOH
I'm not sure if you could call it while holding page table lock or not.
No, VM_MAYSHARE is set on many other kinds of mapping too; and is not
set on all mappings of shmem objects - there is no good reason to
include SysV shm segments here, yet omit other kinds of shmem object
(/dev/shm POSIX shared memory, shared-anonymous mappings, mappings of
tmpfs files).
Not acceptable, I'm afraid. Nothing wrong with a fix-up-afterwards
approach as such, but it's assuming that the vma covers the full extent
of the shmem object. That is very often the case, but by no means
necessarily so (whereas it is always the case that one vma cannot cover
more than one object). So you do have to count pageslot by pageslot.
There are two reasons why I think you have to abandon this. One is
that /proc/<pid>/smaps is reporting on the userspace mappings, saying
where swap is instanced in them. Some of those mappings may be of
shmem objects, and some of those shmem objects may use swap backing
themselves, but that's different from the mapping using swap directly.
One can argue about that distinction, but it is how all this is
designed, and blurring that distinction tends to get into trouble.
(It's reasonable to think of anonymous mappings as mappings of anon
objects, which just happen to find room for the swp_entry in the page
table: but then it's a happy accident that smaps can see them.)
The second reason is that since 2.6.34, /proc/<pid>/status shows
VmSwap: we would not want a huge discrepancy between what it shows
in swap and what /proc/<pid>/smaps shows in swap, but nor would we
want to make /proc/<pid>/status scan through page tables enquiring
of shmem.
All this stands in contrast to your /proc/sysvipc/shm patch, which
is rightly dealing with one class of shmem object, not via mappings
of those objects.
There is a case for a "where has my swap gone" tool, which examines
the different kinds of object involved (anonymous mappings as well
as shmem objects), and shows them all somehow. But that's a lot
more work than just extending an existing stats display.
Hugh
--
