> I'm very grateful for all comments about problems with freeing shared
> memory. I have still no answer to the question about removing the
> page cache page from processes page table, if page->count=1.
Those pages are removed by shrink_mmap in mm/filemape.c. Briefly
scanning code (again ;) I think I see why the page cache behaves poorly:
pages in the page cache do not appear to be aged - shrink_mmap performs
circular scanning of pages in the system... but get_free_page *always*
allocates from one end of the page pool. In effect the shrink_mmap will
almost randomly determine which page to free, or at least very unfairly.
> Does it mean that informations in mm.h are wrong and page->count=1
> for pages, which do not belong to any process and are still in the
> page cache (the swapping mechanism sets the present bit in the page table
> to zero and the page still remains in memory)?
To quote include/linux/mm.h:
* For pages belonging to inodes, the page->count is the number of
* attaches, plus 1 if buffers are allocated to the page.
That's phrased a bit awkwardly, but is the case (read 'if buffers...' as 'if
the page is in the page cache').
> It would mean that (if swapping is inactive) any code page belonging to any
> process is shared until all processes using it terminate (ie. page->count
> =number_of_processes_using_the_page+1)?
Exactly!
-ben