The fact that I didn't bother to get involved doesn't mean that I don't understand the issues of large monolithic programs and those who write them. As I pointed out in my other post, there are so many ways to avoid the issue that it's just barely conceivable that the problem needs to be addressed. I remember reading, perhaps 10 years ago, about the potential need for OSes that would managed segmented 64-bit memory spaces. I admit that I haven't kept up with the subject, but is such a thing really needed? Pointers would be enormous, at 64 bits plus the size of a segment. There are so many ways to avoid the issue that I just don't see it as a problem - mostly because of the time it takes to load gigabytes of data in the first place.

I have seen some presentations saying latest AMD processors support Tagged TLBs and hence they are better than Intel for virtualization.

However, I dont know how kernels use it.

I agree that there will be many solutions to improve IPC between two processes.
But, my point here is that current address space organization requires TLB flush on every process switch by scheduler. This results in performance penalty. I am trying to solve this problem.

Please have a look at http://citeseerx.ist.psu.edu/viewdoc...10.1.1.12.8854 if you are still not convinced.

If you do not flush the TLB, won't you run the risk of process space(including data) pollution by other tasks? You would also be in the position of "reserving" specific addresses within memory for individual tasks. The net result would be a poor usage of available memory, with no ability to sense process memory faults, etc. This wouldn't be well suited for a multi-tasking multi-user OS. Bad, bad, bad.

I see TLB flushing as a feature, not as a problem. As someone else already indicated, you do not want to have unrestricted access between processes to the same data space. This is not Windows, nor do we want it to be. Memory management is properly addressed by the OS, not by the user space. The TLB is the method available to control memory management. It's not a bad method.

I still think you should go to the Memory Management page I put up, and start your journey there and with the MM developers.

Good luck.

I've got the required inputs from people who tried to understand this positively.

Thank you very much.

Regards,
Kailas