On Thu, 4 Aug 2005, Andi Kleen wrote: > > So your point of view is that there will be no control and monitoring of > > the memory usage and policies? > > External control is implemented for named objects and for process policy. > A process can also monitor its own policies if it wants.
Named objects like files and not processes and/or threads? But then these named objects do not have memory allocated to them. > I think the payoff for external monitoring of policies vs complexity > and cleanliness of interface and long term code impact is too bad to make > it an attractive option. Well the implementation has the following issues right now: 1. BIND policy implemented in a way that fills up nodes from the lowest to the higest instead of allocating memory on the local node. 2. No separation between sys_ and do_ functions. Therefore difficult to use from kernel context. 3. Functions have weird side effect (f.e. get_nodes updating and using cpuset policies). Code is therefore difficult to maintain. 4. Uses bitmaps instead of nodemask_t. 5. No means to figure out where the memory was allocated although mempoliy.c implements scans over ptes that would allow that determination. 6. Needs hook into page migration layer to move pages to either conform to policy or to move them menually. The long term impact of this missing functionality is already showing in the numbers of workarounds that I have seen at a various sites, The code is currently complex and difficult to handle because some of the issues mentioned above. We need to fix this in order to have clean code and in order to control future complexity. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
