On 01/14/2015 09:57 PM, Tejun Heo wrote: > Hello, Lai. > > On Wed, Jan 14, 2015 at 10:47:16AM +0800, Lai Jiangshan wrote: >>> 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. > > The problem is that working around this in workqueue effectively hides > what needs to be actively looked upon and decided. It curently isn't > currently defined even when such mappings can change or for which > cpus? Are all offline cpus up for grabs or just !present ones? These > are questions which can only be answered / determined from NUMA side > and the sooner we deal with this properly the better.
So the solution_B totally keeps away from this spaghetti. > >>> 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. > > Exactly, whoever is requiring NUMA node remapping should explain and > justify that and how the model to handle it can only be determined > from that. > > 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/
