On Thu, Aug 04, 2005 at 07:11:36AM -0700, Christoph Lameter wrote: > On Wed, 3 Aug 2005, Andi Kleen wrote: > > > I really hate this whole /proc/<pid>/numa_policy thing. /proc/<pid>/maps > > was imho always a desaster (hard to parse, slow etc.). Also external > > access of NUMA policies has interesting locking issues. I intentionally > > didn't add something like that when I designed the original > > NUMA API. Please don't add it. > > You designed a NUMA API to control a process memory access patterns > without the ability to view or modify the policies in use?
Processes internally can get the information if they want. Externally I didn't expose it intentionally to avoid locking problems > The locking issues for the policy information in the task_struct could be > solved by having a thread execute a function that either sets or gets the > memory policy. The vma policies already have a locking mechanism. But why? It all only adds complexity. Keep it simple please. > > This piece here only does conversion to a string representation so it > should not be affected by locking issues. Processes need to do proper > locking when using the conversion functions. It's useless. -Andi - 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/
