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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |