Andi Kleen wrote: >>No it wont. If you know that you are going to start a process that must >>run on node 3 and know its going to use 2G but there is only 1G free >>then you may want to modify the policy of an existing huge process on >>node 3that is still allocating to go to node 2 that just happens to have >>free space. > > I think you should leave that to the kernel. > But the kernel doesn't know about these future requirements. A batch scheduler does. > >>>>A batch scheduler may anticipate memory shortages and redirect memory >>>>allocations in order to avoid page migration. >>> >>>I think that jobs more belongs to the kernel. After all we don't >>>want to move half of our VM into your proprietary scheduler. >> >>Care to tell me which proprietary scheduler you are talking about? I was > > > That SGI batch scheduler with its incredibly long specification > list you guys seem to want to mess up all interfaces > for. If I can download source to it please supply an URL. I think SGI are just trying to facilitate users (like us) with our own schedulers. > > >>And you are now going to implement automatic page migration into the >>existing scheduler? > > > Hmm? You mean the kernel CPU scheduler? Nobody is planning to add > page migration to that. Exactly. Some of us think we can do a half decent job of manually controlling page migration. What is the harm in letting us "shoot ourselves in the foot" trying? -- -------------------------------------------------------------------------- ANU Supercomputer Facility David.Singleton@anu.edu.au and APAC National Facility Phone: +61 2 6125 4389 Leonard Huxley Bldg (No. 56) Fax: +61 2 6125 8199 Australian National University Canberra, ACT, 0200, Australia -------------------------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Jul 15 20:00:51 2005
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:40 EST