On 01/13/2015 11:22 PM, Tejun Heo wrote: > Hello, > > On Tue, Jan 13, 2015 at 03:19:09PM +0800, Lai Jiangshan wrote: >> The Mapping of the *online* cpus to nodes is already maintained by numa code. >> >> What the workqueue needs is a special Mapping: >> The Mapping of the *possible* cpus to nodes >> >> But this mapping (if the numa code maintain it) is a trouble: >> "possible" implies the mapping is stable/constant/immutable, it is hard >> to >> ensure it in the numa code. >> >> if mutability of this mapping is acceptable, we just move 20~40 LOC >> of code from workqueue to numa code, all the other complexities >> about it are still in workqueue.c. > > Make numa code maintain the mapping to the best of its knowledge and > invoke notification callbacks when it changes.
The best of its knowledge is the physical onlined nodes and CPUs. The cpu_present_mask can represent this knowledge. But it lacks of the per-node cpu_present_mask and the notification callbacks. > Even if that involves slightly more code, that's the right thing to do at > this point. Right, but in currently, the workqueue will be the only user, and I don't known asking who to do it, so I may keep it in the workqueue.c. > This puts the logic which is complicated by the fact that the mapping may > change where it's caused not some random unrelated place. > It'd be > awesome if somebody more familiar with the numa side can chime in and > explain why this mapping change can't be avoided. I'm also looking for someone answer it. > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
