> From [email protected] Tue Apr 16 10:45:28 2013 > the concern that too many mappings can hog all resources is unfounded. > The modern Unix and Linux kernels protect themselves from such > problems.
It's good that somebody thought about algorithmic issues at this level. The lesson in the above is that the right mindset to take for everyone who writes software that will sit at the core of many applications is to make sure that the algorithms employed will behave well both on their own and when there may be interactions with others. These issues are subtle and the algorithmic problems concerning them tend to be hard from a theoretical complexity point of view. So, any implemented solutions will often have gaps. Even if these gaps are low probability events, they can be harmful when hit. It's good that kernel developers, over a long period of time, have continued to evolve their work in the right way to close those gaps. But it's likely that it won't be hard to think of test cases that would bring a system to its knees. The core AST libs are at a layer above the kernel but they are in a similar situation. Think about how different libs may be used together for different reasons, e.g., Sfio to read large files sequentially or CDT to keep large on-line databases in shared memory, etc. Then, also think about how very large applications may run on servers shared by many users. We have systems here that run 24/7 on hundreds of large servers distributed throughout the country to maintain our core network. Our software must safeguard themselves against extraordinary situations. This is what we have tried to do with our core libraries. Back to Sfio, mmap is a just one aspect of the IO subsystem that includes things such as discipline functions to replace the normal system calls. But, we do think that we understand what need be done to obviate the observed performance issue. There is no need to rush into something that we may regret later. Please be patient. Phong _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
