There are a whole pile of valid answers. Those happen to be good ones.
Fixing the application to use clone() not 4000 individual sets of page
tables might not be a bad plan either.
On a more practical note its been true for years but nobody needed the
memory to implement it that you can discard page tables for non anonymous
objects when you need space (arguably they belong on the lru like
everything else) and you can page anonymous maps to disk, although you must
use software not hardware assisted stuff for this due to x86 cpu bugs,
and a complete lack of pageable page table walking hardware in many
processors.
Do each of your tasks map the stuff at the same address. If you are
assuming this how do you plan to handle the person who doesn't. You won't
be able to share page tables then ?
For the shared case then yes sharing pte pages potentially works, but you
have to handle a lot of nasty corner cases buried in vm code like mremap
and mprotect which badly need rewriting before anyone tackles hacking more
crap into them. The rmap would need to know the vma in this case rather
than the pages since the pages would be mapped identically to each user
of the vma and the page cannot be present/absent in different tasks when
the pte is shared
So you need to clean up the uglies in the mm operations, implement reference
counting structures for ptes, hashes to find them, code to page them and
to do accounting on them, rebalance the vm after you do this, fix all of
the unsharing cases to be correct, verify them, make them lock safe against
truncate, disk writes, asynchronous I/O, sendfile and each other.
Can you even make that work -before- the customers have all upgraded
anyway ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/