by Ricardo Neri

[permalink] [raw]

Subject: Re: [PATCH v3 07/24] sched/fair: Compute IPC class scores for load balancing

On Fri, Mar 31, 2023 at 02:20:11PM +0200, Vincent Guittot wrote:
> On Thu, 30 Mar 2023 at 03:56, Ricardo Neri
> <[email protected]> wrote:
> >
> > On Tue, Mar 28, 2023 at 12:00:58PM +0200, Vincent Guittot wrote:
> > > On Tue, 7 Feb 2023 at 06:01, Ricardo Neri
> > > <[email protected]> wrote:
> > > >
> > > > Compute the joint total (both current and prospective) IPC class score of
> > > > a scheduling group and the local scheduling group.
> > > >
> > > > These IPCC statistics are used during idle load balancing. The candidate
> > > > scheduling group will have one fewer busy CPU after load balancing. This
> > > > observation is important for cores with SMT support.
> > > >
> > > > The IPCC score of scheduling groups composed of SMT siblings needs to
> > > > consider that the siblings share CPU resources. When computing the total
> > > > IPCC score of the scheduling group, divide score of each sibling by the
> > > > number of busy siblings.
> > > >
> > > > Collect IPCC statistics for asym_packing and fully_busy scheduling groups.
> > >
> > > IPCC statistics collect scores of current tasks, so they are
> > > meaningful only when trying to migrate one of those running tasks.
> > > Using such score when pulling other tasks is just meaningless. And I
> > > don't see how you ensure such correct use of ipcc score
> >
> > Thank you very much for your feedback Vincent!
> >
> > It is true that the task that is current when collecting statistics may be
> > different from the task that is current when we are ready to pluck tasks.
> >
> > Using IPCC scores for load balancing benefits large, long-running tasks
> > the most. For these tasks, the current task is likely to remain the same
> > at the two mentioned points in time.
>
> My point was mainly about the fact that the current running task is
> the last one to be pulled. And this happens only when no other task
> was pulled otherwise.

(Thanks again for your feedback, Vincent. I am sorry for the late reply. I
needed some more time to think about it.)

Good point! It is smarter to compare and pull from the back of the queue,
rather than comparing curr and pulling from the back. We are more likely
to break the tie correctly without being too complex.

Here is an incremental patch with the update. I'll include this change in
my next version.

@@ -9281,24 +9281,42 @@ static void init_rq_ipcc_stats(struct sg_lb_stats *sgs)
sgs->min_score = ULONG_MAX;
}

+static int rq_last_task_ipcc(int dst_cpu, struct rq *rq, unsigned short *ipcc)
+{
+ struct list_head *tasks = &rq->cfs_tasks;
+ struct task_struct *p;
+ struct rq_flags rf;
+ int ret = -EINVAL;
+
+ rq_lock_irqsave(rq, &rf);
+ if (list_empty(tasks))
+ goto out;
+
+ p = list_last_entry(tasks, struct task_struct, se.group_node);
+ if (p->flags & PF_EXITING || is_idle_task(p) ||
+ !cpumask_test_cpu(dst_cpu, p->cpus_ptr))
+ goto out;
+
+ ret = 0;
+ *ipcc = p->ipcc;
+out:
+ rq_unlock(rq, &rf);
+ return ret;
+}
+
/* Called only if cpu_of(@rq) is not idle and has tasks running. */
static void update_sg_lb_ipcc_stats(int dst_cpu, struct sg_lb_stats *sgs,
struct rq *rq)
{
- struct task_struct *curr;
unsigned short ipcc;
unsigned long score;

if (!sched_ipcc_enabled())
return;

- curr = rcu_dereference(rq->curr);
- if (!curr || (curr->flags & PF_EXITING) || is_idle_task(curr) ||
- task_is_realtime(curr) ||
- !cpumask_test_cpu(dst_cpu, curr->cpus_ptr))
+ if (rq_last_task_ipcc(dst_cpu, rq, &ipcc))
return;

- ipcc = curr->ipcc;
score = arch_get_ipcc_score(ipcc, cpu_of(rq));

>
> >
> > My patchset proposes to use IPCC clases to break ties between otherwise
> > identical sched groups in update_sd_pick_busiest(). Its use is limited to
> > asym_packing and fully_busy types. For these types, it is likely that there
> > will not be tasks wanting to run other than current. need_active_balance()
> > will return true and we will migrate the current task.
>
> I disagree with your assumption above, asym_packing and fully_busy
> types doesn't put any mean on the number of running tasks

Agreed. What I stated was not correct.

o>
> >
> > You are correct, by only looking at the current tasks we risk overlooking
> > other tasks in the queue and the statistics becoming meaningless. A fully
> > correct solution would need to keep track of the the types of tasks in
> > all runqueues as they come and go. IMO, the increased complexity of such
> > approach does not justify the benefit. We give the load balancer extra
> > information to decide between otherwise identical sched groups using the
> > IPCC statistics of big tasks.
>
> because IPCC are meaningful only when there is only 1 running task and
> during active migration, you should collect them only for such
> situation

I think that if we compute the IPCC statistics using the tasks at the back
of the runqueue, then IPCC statistics remain meaningful for nr_running >= 1.

2023-04-17 23:11:09

by Ricardo Neri

[permalink] [raw]

Subject: Re: [PATCH v3 10/24] sched/fair: Use IPCC scores to select a busiest runqueue

On Fri, Mar 31, 2023 at 02:23:58PM +0200, Vincent Guittot wrote:
> On Thu, 30 Mar 2023 at 04:03, Ricardo Neri
> <[email protected]> wrote:
> >
> > On Tue, Mar 28, 2023 at 12:03:58PM +0200, Vincent Guittot wrote:
> > > On Tue, 7 Feb 2023 at 06:01, Ricardo Neri
> > > <[email protected]> wrote:
> > > >
> > > > For two runqueues of equal priority and equal number of running of tasks,
> > > > select the one whose current task would have the highest IPC class score
> > > > if placed on the destination CPU.
> > >
> > > You failed to explain why it make sense to compare current task score
> > > whereas we will most probably not pull this task at the end
> >
> > Thank you for your feedback Vincent! Please kindly refer to my reply to
> > your feedback in patch 7.
> >
> > > >
> > > > For now, use IPCC scores only for scheduling domains with the
> > > > SD_ASYM_PACKING flag.
> > > >
> > > > Cc: Ben Segall <[email protected]>
> > > > Cc: Daniel Bristot de Oliveira <[email protected]>
> > > > Cc: Dietmar Eggemann <[email protected]>
> > > > Cc: Ionela Voinescu <[email protected]>
> > > > Cc: Joel Fernandes (Google) <[email protected]>
> > > > Cc: Len Brown <[email protected]>
> > > > Cc: Lukasz Luba <[email protected]>
> > > > Cc: Mel Gorman <[email protected]>
> > > > Cc: Rafael J. Wysocki <[email protected]>
> > > > Cc: Srinivas Pandruvada <[email protected]>
> > > > Cc: Steven Rostedt <[email protected]>
> > > > Cc: Tim C. Chen <[email protected]>
> > > > Cc: Valentin Schneider <[email protected]>
> > > > Cc: [email protected]
> > > > Cc: [email protected]
> > > > Cc: [email protected]
> > > > Signed-off-by: Ricardo Neri <[email protected]>
> > > > ---
> > > > Changes since v2:
> > > > * Only use IPCC scores to break ties if the sched domain uses
> > > > asym_packing. (Ionela)
> > > > * Handle errors of arch_get_ipcc_score(). (Ionela)
> > > >
> > > > Changes since v1:
> > > > * Fixed a bug when selecting a busiest runqueue: when comparing two
> > > > runqueues with equal nr_running, we must compute the IPCC score delta
> > > > of both.
> > > > * Renamed local variables to improve the layout of the code block.
> > > > (PeterZ)
> > > > * Used the new interface names.
> > > > ---
> > > > kernel/sched/fair.c | 64 +++++++++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 64 insertions(+)
> > > >
> > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > index 72d88270b320..d3c22dc145f7 100644
> > > > --- a/kernel/sched/fair.c
> > > > +++ b/kernel/sched/fair.c
> > > > @@ -9399,6 +9399,37 @@ static bool sched_asym_ipcc_pick(struct sched_group *a,
> > > > return sched_asym_ipcc_prefer(a_stats, b_stats);
> > > > }
> > > >
> > > > +/**
> > > > + * ipcc_score_delta - Get the IPCC score delta wrt the load balance's dst_cpu
> > > > + * @p: A task
> > > > + * @env: Load balancing environment
> > > > + *
> > > > + * Returns: The IPCC score delta that @p would get if placed in the destination
> > > > + * CPU of @env. LONG_MIN to indicate that the delta should not be used.
> > > > + */
> > > > +static long ipcc_score_delta(struct task_struct *p, struct lb_env *env)
> > > > +{
> > > > + unsigned long score_src, score_dst;
> > > > + unsigned short ipcc = p->ipcc;
> > > > +
> > > > + if (!sched_ipcc_enabled())
> > > > + return LONG_MIN;
> > > > +
> > > > + /* Only asym_packing uses IPCC scores at the moment. */
> > > > + if (!(env->sd->flags & SD_ASYM_PACKING))
> > > > + return LONG_MIN;
> > > > +
> > > > + score_dst = arch_get_ipcc_score(ipcc, env->dst_cpu);
> > > > + if (IS_ERR_VALUE(score_dst))
> > > > + return LONG_MIN;
> > > > +
> > > > + score_src = arch_get_ipcc_score(ipcc, task_cpu(p));
> > > > + if (IS_ERR_VALUE(score_src))
> > > > + return LONG_MIN;
> > > > +
> > > > + return score_dst - score_src;
> > > > +}
> > > > +
> > > > #else /* CONFIG_IPC_CLASSES */
> > > > static void update_sg_lb_ipcc_stats(int dst_cpu, struct sg_lb_stats *sgs,
> > > > struct rq *rq)
> > > > @@ -9429,6 +9460,11 @@ static bool sched_asym_ipcc_pick(struct sched_group *a,
> > > > return false;
> > > > }
> > > >
> > > > +static long ipcc_score_delta(struct task_struct *p, struct lb_env *env)
> > > > +{
> > > > + return LONG_MIN;
> > > > +}
> > > > +
> > > > #endif /* CONFIG_IPC_CLASSES */
> > > >
> > > > /**
> > > > @@ -10589,6 +10625,7 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> > > > {
> > > > struct rq *busiest = NULL, *rq;
> > > > unsigned long busiest_util = 0, busiest_load = 0, busiest_capacity = 1;
> > > > + long busiest_ipcc_delta = LONG_MIN;
> > > > unsigned int busiest_nr = 0;
> > > > int i;
> > > >
> > > > @@ -10705,8 +10742,35 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> > > >
> > > > case migrate_task:
> > > > if (busiest_nr < nr_running) {
> > > > + struct task_struct *curr;
> > > > +
> > > > busiest_nr = nr_running;
> > > > busiest = rq;
> > > > +
> > > > + /*
> > > > + * Remember the IPCC score delta of busiest::curr.
> > > > + * We may need it to break a tie with other queues
> > > > + * with equal nr_running.
> > > > + */
> > > > + curr = rcu_dereference(busiest->curr);
> > > > + busiest_ipcc_delta = ipcc_score_delta(curr, env);
> > >
> > > Hmm, i don't like this at all
> > >
> > > Also, curr is the least probable task to be pulled which means that
> > > all this his useless
> >
> > but when doing asym_packing balancing nr_running = 1, need_active_balance()
> > returns true and we will pull the current task, no? This is also true for
> > fully_busy groups with one task per CPU. These are the only two cases that
> > currently use IPCC scores.
>
> hmm, for sure it's not true for fully_busy and I don't see anything
> about asym_packing mandating that nr_running = 1

I meant to say that if nr_running = 1, we would pull the running task
because there is nothing else to pull.

Just as when identifying the busiest group, we can instead break the tie
using the task at the back of the runqueue. We will start with this task
when migrating tasks.

>
> You should have a look at misfit task which seems to better fit your
> situation where you have one task that doesn't fit its cpu instead of
> adding such condition

Thank you for the suggestion! I did take a look. When dealing with misfit
tasks, we identify one task that is too big for a small CPU. The
destination CPU is not needed when updating the misfit status.

On the other hand, identifying the “an IPCC-misfit” task (similar to
update_misfit_status()) would require knowing the destination CPU, of which
there may be more than one type. We could compute the IPCC-misfit status
for all prospective destinations CPU types but that may introduce a non-
trivial overhead and would be too complex for a tie breaker, IMO.

Unlike migrate_misfit, we would not take immediate action but use IPCC
scores to improve the selection of the busiest runqueue.