On Thu 30-05-19 20:55:32, Pingfan Liu wrote: > On Wed, May 29, 2019 at 2:20 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > [Sorry for a late reply] > > > > On Thu 23-05-19 11:58:45, Pingfan Liu wrote: > > > On Wed, May 22, 2019 at 7:16 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > > > On Wed 22-05-19 15:12:16, Pingfan Liu wrote: > > [...] > > > > > But in fact, we already have for_each_node_state(nid, N_MEMORY) to > > > > > cover this purpose. > > > > > > > > I do not really think we want to spread N_MEMORY outside of the core MM. > > > > It is quite confusing IMHO. > > > > . > > > But it has already like this. Just git grep N_MEMORY. > > > > I might be wrong but I suspect a closer review would reveal that the use > > will be inconsistent or dubious so following the existing users is not > > the best approach. > > > > > > > Furthermore, changing the definition of online may > > > > > break something in the scheduler, e.g. in task_numa_migrate(), where > > > > > it calls for_each_online_node. > > > > > > > > Could you be more specific please? Why should numa balancing consider > > > > nodes without any memory? > > > > > > > As my understanding, the destination cpu can be on a memory less node. > > > BTW, there are several functions in the scheduler facing the same > > > scenario, task_numa_migrate() is an example. > > > > Even if the destination node is memoryless then any migration would fail > > because there is no memory. Anyway I still do not see how using online > > node would break anything. > > > Suppose we have nodes A, B,C, where C is memory less but has little > distance to B, comparing with the one from A to B. Then if a task is > running on A, but prefer to run on B due to memory footprint. > task_numa_migrate() allows us to migrate the task to node C. Changing > for_each_online_node will break this. That would require the task to have preferred node to be C no? Or do I missunderstand the task migration logic? -- Michal Hocko SUSE Labs
