>In my opinion, with CPUs getting ever faster plus recent memory >technology developments that reduce memory access latency, yet hard >disk access remaining slow (in comparison) it is now worth spending >more CPU cycles on getting memory management "right". This trend >will no doubt continue unless something big happens in the commercial >mass storage industry. I agree that VM seems the best choice. >I think the biggest problem facing a more "intelligent" VM would be > >i) debugging it Yes this could be a big problem. If the existing systems are difficult to debug, it would only be harder if a learning system is adding some black magic to the mix. One way to help is to have the learning system choose from a set of simple VM systems. If each system performed well under different circumstances the learning could just figure out which one was appropriate for the current situation. (Or perhaps even better, do a weighted vote on which page to remove.) Since each VM system is separate they could be debugged individually. >ii) making a dudicious selection of scenarios to base the >intelligence on. I need to know more about the VM system before I can make any concrete suggestions. (Particularly about where the existing systems have problems.) Still I like the idea of combining a set of VM algorithms. It dovetails nicely with my own research in machine learning. All it needs is a relatively cheap set of VM systems. (It is possible to use just one VM system that can be configured with parameters. The set of algorithms would then be the single algorithm with different parameters. This would allow a space savings since all the code would be the same and may even allow some computational savings if the algorithms performed some of the same computations.) The feedback should be easy since the system will tell us which pages are used in the future. >Could this intelligence be handled from user space? Because an >intelligent VM is starting to look like policy (to me at least), >could it be done outside the kernel by monitoring VM stats in /proc >and adjusting kernel parameters appropriately? Has this already been >done?=20 Of course, there is the problem that the VM monitor could be >denied sufficient CPU time when the system is under heavy load... and >that is when VM really needs to be doing its stuff! I guess this would depend on how it was used. It could be used 1) All the time, and therefore it would need to stay in memory. 2) In the background to help tune to the specific machine. It wouldn't handle dynamic situations; it would just try to improve the average performance of a fixed VM policy. 3) Only when the system was really falling apart. Again it would need to be in memory, but at least you would only pay when the system really needed it. Thanks for the help, and I would appreciate any comments or suggestions on the above ideas. Chris Mesterharm -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
