So I think that this review is mostly accurate. My real questions are:
1) Why muck with the well-understood memory object model? 2) Mach won't use more memory under my proposal; you have simply moved around where the memory is. Instead of taking more memory to hold a table of physical->virtual address mappings in the memory object, you have a table of virtual->backing_store mappings in the pager; but it is the same data and it has to be stored either way. 3) I REALLY REALLY prefer keeping the memory object interface clear; experience is that this is a huge source of constant bugs. In addition, adopting your strategy is way tougher to debug, because it's a big kernel change, rather than a simple user-space one. 4) And finally, what about data caching--which is vastly more important than mapping caching? My version has it that data is cached as long as the kernel wants to keep it around, and in a fashion decoupled from mappings. But the moral of Neil's analysis is basically a good one: his proposal and mine do the same tasks, but in different places. My proposal is better because it does these tasks in user space. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
