On Sat, 16 Jul 2005, Paul Jackson wrote: > I'm missing something here. Are you saying that just a change to > libnuma would suffice to accomplish what you sought with this patch?
Its a quite significant change but yes of course you can do that if you really favor libnuma and IMHO want to make it difficult to maintain and to use. > If that's the case, we don't need a kernel patch, right? Sure. > And despite Andi's urging us to only access these facilities via > libnuma, there is no law to that affect that I know of. At the least, > you could present user level only code that accomplished the object > of this patch set, with no kernel change. Sure you can write a series of tools that accomplish the same. > I don't think that is possible, short of gross hackery on /dev/mem. > I think some sort of kernel change is required to enable one task to > change the numa policy of another task. Yes doing what I said to libnuma would require a significant rework of the APIs and the kernel libnuma stuff. Its easier to implement the whole thing using /proc, then no libraries would need to be modified, no tools need to be written. Just accept the patch that I posted, fix up whatever has to be fixed and we are done. - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
