Messages in this thread | | | From | Vincent Guittot <> | Date | Tue, 21 Dec 2021 14:05:59 +0100 | Subject | Re: [PATCH 1/2] sched/fair: Use weight of SD_NUMA domain in find_busiest_group |
| |
On Tue, 21 Dec 2021 at 12:32, Mel Gorman <mgorman@techsingularity.net> wrote: > > On Tue, Dec 21, 2021 at 11:53:50AM +0100, Vincent Guittot wrote: > > On Fri, 10 Dec 2021 at 10:33, Mel Gorman <mgorman@techsingularity.net> wrote: > > > > > > find_busiest_group uses the child domain's group weight instead of > > > the sched_domain's weight that has SD_NUMA set when calculating the > > > allowed imbalance between NUMA nodes. This is wrong and inconsistent > > > with find_idlest_group. > > > > I agree that find_busiest_group and find_idlest_group should be > > consistent and use the same parameters but I wonder if sched_domain's > > weight is the right one to use instead of the target group's weight. > > > > Ok > > > IIRC, the goal of adjust_numa_imbalance is to keep some threads on the > > same node as long as we consider that there is no performance impact > > because of sharing resources as they can even take advantage of > > locality if they interact. > > Yes. > > > So we consider that tasks will not be > > impacted by sharing resources if they use less than 25% of the CPUs of > > a node. If we use the sd->span_weight instead, we consider that we can > > pack threads in the same node as long as it uses less than 25% of the > > CPUs in all nodes. > > > > I assume you mean the target group weight instead of the node. The
I wanted to say that with this patch, we consider the imbalance acceptable if the number of threads in a node is less than 25% of all CPUs of all nodes (for this numa level) , but 25% of all CPUs of all nodes can be more that the number of CPUs in the group.
So I would have changed find_idlest_group instead of changing find_busiest_group
> primary resource we are concerned with is memory bandwidth and it's a > guess because we do not know for sure where memory channels are or how > they are configured in this context and it may or may not be correlated > with groups. I think using the group instead would deserve a series on > its own after settling on an imbalance number when there are multiple > LLCs per node.
I haven't look yet at the patch2 for multiple LLC per node
> > -- > Mel Gorman > SUSE Labs
| |