On Mon, 2002-01-21 at 10:31, Zwane Mwaikambo wrote: ------------8<--------------8<---------------- > One thing to watch out for is overhead when doing your > "calculations" the VM shouldn't eat too much CPU time... It is a question of what "too much" is. 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 think the biggest problem facing a more "intelligent" VM would be i) debugging it ii) making a dudicious selection of scenarios to base the intelligence on. Could it be that the time has come to stop looking for the "golden"/One Size Fits All(tm) VM algo (i.e. simple, inexpensive, good under all loads) and spend that time on devising a good intelligence system? I think Riks VM was headed this way before Linus ripped it out. I think this point has been demonstrated by the VM switch half way thru 2.4.x, we now have a VM that is different but only better in some situations. I think the time has come for a change in attitude and approach to VM and formalised artificial intelligence might just be the way forward. 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? 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! Go ahead VM guys, shoot my simplistic views down in flames! ;) -- best regards, Andy
Attachment:
signature.asc
Description: This is a digitally signed message part
