On Tue, Feb 1, 2022 at 10:39 PM Srikar Dronamraju
<[email protected]> wrote:
>
> * Barry Song <[email protected]> [2022-01-28 07:40:15]:
>
> > On Fri, Jan 28, 2022 at 8:13 PM Srikar Dronamraju
> > <[email protected]> wrote:
> > >
> > > * Barry Song <[email protected]> [2022-01-28 09:21:08]:
> > >
> > > > On Fri, Jan 28, 2022 at 4:41 AM Gautham R. Shenoy
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Wed, Jan 26, 2022 at 04:09:47PM +0800, Yicong Yang wrote:
> > > > > > From: Barry Song <[email protected]>
> > > > > >
> > > > > > For platforms having clusters like Kunpeng920, CPUs within the same
> > > > > > cluster have lower latency when synchronizing and accessing shared
> > > > > > resources like cache. Thus, this patch tries to find an idle cpu
> > > > > > within the cluster of the target CPU before scanning the whole LLC
> > > > > > to gain lower latency.
> > > > > >
> > > > > > Note neither Kunpeng920 nor x86 Jacobsville supports SMT, so this
> > > > > > patch doesn't consider SMT for this moment.
> > > > > >
> > > > > > Testing has been done on Kunpeng920 by pinning tasks to one numa
> > > > > > and two numa. On Kunpeng920, Each numa has 8 clusters and each
> > > > > > cluster has 4 CPUs.
> > > > > >
> > > > > > With this patch, We noticed enhancement on tbench within one
> > > > > > numa or cross two numa.
> > > > > >
> > > > > > On numa 0:
> > > > > > 5.17-rc1 patched
> > > > > > Hmean 1 324.73 ( 0.00%) 378.01 * 16.41%*
> > > > > > Hmean 2 645.36 ( 0.00%) 754.63 * 16.93%*
> > > > > > Hmean 4 1302.09 ( 0.00%) 1507.54 * 15.78%*
> > > > > > Hmean 8 2612.03 ( 0.00%) 2982.57 * 14.19%*
> > > > > > Hmean 16 5307.12 ( 0.00%) 5886.66 * 10.92%*
> > > > > > Hmean 32 9354.22 ( 0.00%) 9908.13 * 5.92%*
> > > > > > Hmean 64 7240.35 ( 0.00%) 7278.78 * 0.53%*
> > > > > > Hmean 128 6186.40 ( 0.00%) 6187.85 ( 0.02%)
> > > > > >
> > > > > > On numa 0-1:
> > > > > > 5.17-rc1 patched
> > > > > > Hmean 1 320.01 ( 0.00%) 378.44 * 18.26%*
> > > > > > Hmean 2 643.85 ( 0.00%) 752.52 * 16.88%*
> > > > > > Hmean 4 1287.36 ( 0.00%) 1505.62 * 16.95%*
> > > > > > Hmean 8 2564.60 ( 0.00%) 2955.29 * 15.23%*
> > > > > > Hmean 16 5195.69 ( 0.00%) 5814.74 * 11.91%*
> > > > > > Hmean 32 9769.16 ( 0.00%) 10872.63 * 11.30%*
> > > > > > Hmean 64 15952.50 ( 0.00%) 17281.98 * 8.33%*
> > > > > > Hmean 128 13113.77 ( 0.00%) 13895.20 * 5.96%*
> > > > > > Hmean 256 10997.59 ( 0.00%) 11244.69 * 2.25%*
> > > > > > Hmean 512 14623.60 ( 0.00%) 15526.25 * 6.17%*
> > > > > >
> > > > > > This will also help to improve the MySQL. With MySQL server
> > > > > > running on numa 0 and client running on numa 1, both QPS and
> > > > > > latency is imporved on read-write case:
> > > > > > 5.17-rc1 patched
> > > > > > QPS-16threads 143333.2633 145077.4033(+1.22%)
> > > > > > QPS-24threads 195085.9367 202719.6133(+3.91%)
> > > > > > QPS-32threads 241165.6867 249020.74(+3.26%)
> > > > > > QPS-64threads 244586.8433 253387.7567(+3.60%)
> > > > > > avg-lat-16threads 2.23 2.19(+1.19%)
> > > > > > avg-lat-24threads 2.46 2.36(+3.79%)
> > > > > > avg-lat-36threads 2.66 2.57(+3.26%)
> > > > > > avg-lat-64threads 5.23 5.05(+3.44%)
> > > > > >
> > > > > > Tested-by: Yicong Yang <[email protected]>
> > > > > > Signed-off-by: Barry Song <[email protected]>
> > > > > > Signed-off-by: Yicong Yang <[email protected]>
> > > > > > ---
> > > > > > kernel/sched/fair.c | 46 +++++++++++++++++++++++++++++++++++++++++----
> > > > > > 1 file changed, 42 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > > > index 5146163bfabb..2f84a933aedd 100644
> > > > > > --- a/kernel/sched/fair.c
> > > > > > +++ b/kernel/sched/fair.c
> > > > > > @@ -6262,12 +6262,46 @@ static inline int select_idle_smt(struct task_struct *p, struct sched_domain *sd
> > > > > >
> > > > > > #endif /* CONFIG_SCHED_SMT */
> > > > > >
> > > > > > +#ifdef CONFIG_SCHED_CLUSTER
> > > > > > +/*
> > > > > > + * Scan the cluster domain for idle CPUs and clear cluster cpumask after scanning
> > > > > > + */
> > > > > > +static inline int scan_cluster(struct task_struct *p, int prev_cpu, int target)
> > > > > > +{
> > > > > > + struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
> > > > > > + struct sched_domain *sd = rcu_dereference(per_cpu(sd_cluster, target));
> > > > > > + int cpu, idle_cpu;
> > > > > > +
> > > > > > + /* TODO: Support SMT case while a machine with both cluster and SMT born */
> > > > > > + if (!sched_smt_active() && sd) {
> > > > > > + for_each_cpu_and(cpu, cpus, sched_domain_span(sd)) {
> > > > > > + idle_cpu = __select_idle_cpu(cpu, p);
> > > > > > + if ((unsigned int)idle_cpu < nr_cpumask_bits)
> > > > > > + return idle_cpu;
> > > > > > + }
> > > > > > +
> > > > > > + /* Don't ping-pong tasks in and out cluster frequently */
> > > > > > + if (cpus_share_resources(target, prev_cpu))
> > > > > > + return target;
> > > > >
> > > > > We reach here when there aren't any idle CPUs within the
> > > > > cluster. However there might be idle CPUs in the MC domain. Is a busy
> > > > > @target preferable to a potentially idle CPU within the larger domain
> > > > > ?
> > > >
> > > > Hi Gautham,
> > > >
> > >
> > > Hi Barry,
> > >
> > >
> > > > My benchmark showed some performance regression while load was medium or above
> > > > if we grabbed idle cpu in and out the cluster. it turned out the
> > > > regression disappeared if
> > > > we blocked the ping-pong. so the logic here is that if we have scanned
> > > > and found an
> > > > idle cpu within the cluster before, we don't let the task jumping back
> > > > and forth frequently
> > > > as cache synchronization is higher cost. but the code still allows
> > > > scanning out of the cluster
> > > > if we haven't packed waker and wakee together yet.
> > > >
> > >
> > > Like what Gautham said, should we choose the same cluster if we find that
> > > there are no idle-cpus in the LLC? This way we avoid ping-pong if there are
> > > no idle-cpus but we still pick an idle-cpu to a busy cpu?
> >
> > Hi Srikar,
> > I am sorry I didn't get your question. Currently the code works as below:
> > if task A wakes up task B, and task A is in LLC0 and task B is in LLC1.
> > we will scan the cluster of A before scanning the whole LLC0, in this case,
> > cluster of A is the closest sibling, so it is the better choice than other CPUs
> > which are in LLC0 but not in the cluster of A.
>
> Yes, this is right.
>
> > But we do scan all cpus of LLC0
> > afterwards if we fail to find an idle CPU in the cluster.
>
> However my reading of the patch, before we can scan other clusters within
> the LLC (aka LLC0), we have a check in scan cluster which says
>
> /* Don't ping-pong tasks in and out cluster frequently */
> if (cpus_share_resources(target, prev_cpu))
> return target;
>
> My reading of this is, ignore other clusters (at this point, we know there
> are no idle CPUs in this cluster. We don't know if there are idle cpus in
> them or not) if the previous CPU and target CPU happen to be from the same
> cluster. This effectively means we are given preference to cache over idle
> CPU.
Note we only ignore other cluster while prev_cpu and target are in same
cluster. if the condition is false, we are not ignoring other cpus. typically,
if waker is the target, and wakee is the prev_cpu, that means if they are
already in one cluster, we don't stupidly spread them in select_idle_cpu() path
as benchmark shows we are losing. so, yes, we are giving preference to
cache over CPU.
>
> Or Am I still missing something?
>
> >
> > After a while, if the cluster of A gets an idle CPU and pulls B into the
> > cluster, we prefer not pushing B out of the cluster of A again though
> > there might be an idle CPU outside. as benchmark shows getting an
> > idle CPU out of the cluster of A doesn't bring performance improvement
> > but performance decreases as B might be getting in and getting out
> > the cluster of A very frequently, then cache coherence ping-pong.
> >
>
> The counter argument can be that Task A and Task B are related and were
> running on the same cluster. But Load balancer moved Task B to a different
> cluster. Now this check may cause them to continue to run on two different
> clusters, even though the underlying load balance issues may have changed.
>
> No?
LB is much slower than select_idle_cpu(). select_idle_cpu() can dynamically
work afterwards. so it is always a dynamic balance and task migration.
>
>
> --
> Thanks and Regards
> Srikar Dronamraju
Thanks
Barry
* Barry Song <[email protected]> [2022-02-02 09:20:32]:
> On Tue, Feb 1, 2022 at 10:39 PM Srikar Dronamraju
> <[email protected]> wrote:
> >
> > * Barry Song <[email protected]> [2022-01-28 07:40:15]:
> >
> > > On Fri, Jan 28, 2022 at 8:13 PM Srikar Dronamraju
> > > <[email protected]> wrote:
> > > >
> > > > * Barry Song <[email protected]> [2022-01-28 09:21:08]:
> > > >
> > > > > On Fri, Jan 28, 2022 at 4:41 AM Gautham R. Shenoy
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Wed, Jan 26, 2022 at 04:09:47PM +0800, Yicong Yang wrote:
> > > > > > > From: Barry Song <[email protected]>
> > > > > > >
> > > I am sorry I didn't get your question. Currently the code works as below:
> > > if task A wakes up task B, and task A is in LLC0 and task B is in LLC1.
> > > we will scan the cluster of A before scanning the whole LLC0, in this case,
> > > cluster of A is the closest sibling, so it is the better choice than other CPUs
> > > which are in LLC0 but not in the cluster of A.
> >
> > Yes, this is right.
> >
> > > But we do scan all cpus of LLC0
> > > afterwards if we fail to find an idle CPU in the cluster.
> >
> > However my reading of the patch, before we can scan other clusters within
> > the LLC (aka LLC0), we have a check in scan cluster which says
> >
> > /* Don't ping-pong tasks in and out cluster frequently */
> > if (cpus_share_resources(target, prev_cpu))
> > return target;
> >
> > My reading of this is, ignore other clusters (at this point, we know there
> > are no idle CPUs in this cluster. We don't know if there are idle cpus in
> > them or not) if the previous CPU and target CPU happen to be from the same
> > cluster. This effectively means we are given preference to cache over idle
> > CPU.
>
> Note we only ignore other cluster while prev_cpu and target are in same
> cluster. if the condition is false, we are not ignoring other cpus. typically,
> if waker is the target, and wakee is the prev_cpu, that means if they are
> already in one cluster, we don't stupidly spread them in select_idle_cpu() path
> as benchmark shows we are losing. so, yes, we are giving preference to
> cache over CPU.
We already figured out that there are no idle CPUs in this cluster. So dont
we gain performance by picking a idle CPU/core in the neighbouring cluster.
If there are no idle CPU/core in the neighbouring cluster, then it does make
sense to fallback on the current cluster.
>
> >
> > Or Am I still missing something?
> >
> > >
> > > After a while, if the cluster of A gets an idle CPU and pulls B into the
> > > cluster, we prefer not pushing B out of the cluster of A again though
> > > there might be an idle CPU outside. as benchmark shows getting an
> > > idle CPU out of the cluster of A doesn't bring performance improvement
> > > but performance decreases as B might be getting in and getting out
> > > the cluster of A very frequently, then cache coherence ping-pong.
> > >
> >
> > The counter argument can be that Task A and Task B are related and were
> > running on the same cluster. But Load balancer moved Task B to a different
> > cluster. Now this check may cause them to continue to run on two different
> > clusters, even though the underlying load balance issues may have changed.
> >
> > No?
>
> LB is much slower than select_idle_cpu(). select_idle_cpu() can dynamically
> work afterwards. so it is always a dynamic balance and task migration.
>
> >
> >
> > --
> > Thanks and Regards
> > Srikar Dronamraju
>
> Thanks
> Barry
--
Thanks and Regards
Srikar Dronamraju
On Fri, Feb 4, 2022 at 8:33 PM Srikar Dronamraju
<[email protected]> wrote:
>
> * Barry Song <[email protected]> [2022-02-02 09:20:32]:
>
> > On Tue, Feb 1, 2022 at 10:39 PM Srikar Dronamraju
> > <[email protected]> wrote:
> > >
> > > * Barry Song <[email protected]> [2022-01-28 07:40:15]:
> > >
> > > > On Fri, Jan 28, 2022 at 8:13 PM Srikar Dronamraju
> > > > <[email protected]> wrote:
> > > > >
> > > > > * Barry Song <[email protected]> [2022-01-28 09:21:08]:
> > > > >
> > > > > > On Fri, Jan 28, 2022 at 4:41 AM Gautham R. Shenoy
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > On Wed, Jan 26, 2022 at 04:09:47PM +0800, Yicong Yang wrote:
> > > > > > > > From: Barry Song <[email protected]>
> > > > > > > >
> > > > I am sorry I didn't get your question. Currently the code works as below:
> > > > if task A wakes up task B, and task A is in LLC0 and task B is in LLC1.
> > > > we will scan the cluster of A before scanning the whole LLC0, in this case,
> > > > cluster of A is the closest sibling, so it is the better choice than other CPUs
> > > > which are in LLC0 but not in the cluster of A.
> > >
> > > Yes, this is right.
> > >
> > > > But we do scan all cpus of LLC0
> > > > afterwards if we fail to find an idle CPU in the cluster.
> > >
> > > However my reading of the patch, before we can scan other clusters within
> > > the LLC (aka LLC0), we have a check in scan cluster which says
> > >
> > > /* Don't ping-pong tasks in and out cluster frequently */
> > > if (cpus_share_resources(target, prev_cpu))
> > > return target;
> > >
> > > My reading of this is, ignore other clusters (at this point, we know there
> > > are no idle CPUs in this cluster. We don't know if there are idle cpus in
> > > them or not) if the previous CPU and target CPU happen to be from the same
> > > cluster. This effectively means we are given preference to cache over idle
> > > CPU.
> >
> > Note we only ignore other cluster while prev_cpu and target are in same
> > cluster. if the condition is false, we are not ignoring other cpus. typically,
> > if waker is the target, and wakee is the prev_cpu, that means if they are
> > already in one cluster, we don't stupidly spread them in select_idle_cpu() path
> > as benchmark shows we are losing. so, yes, we are giving preference to
> > cache over CPU.
>
> We already figured out that there are no idle CPUs in this cluster. So dont
> we gain performance by picking a idle CPU/core in the neighbouring cluster.
> If there are no idle CPU/core in the neighbouring cluster, then it does make
> sense to fallback on the current cluster.
What you suggested is exactly the approach we have tried at the first beginning
during debugging. but we didn't gain performance according to benchmark, we
were actually losing. that is why we added this line to stop ping-pong:
/* Don't ping-pong tasks in and out cluster frequently */
if (cpus_share_resources(target, prev_cpu))
return target;
If we delete this, we are seeing a big loss of tbench while system
load is medium
and above.
>
> >
> > >
> > > Or Am I still missing something?
> > >
> > > >
> > > > After a while, if the cluster of A gets an idle CPU and pulls B into the
> > > > cluster, we prefer not pushing B out of the cluster of A again though
> > > > there might be an idle CPU outside. as benchmark shows getting an
> > > > idle CPU out of the cluster of A doesn't bring performance improvement
> > > > but performance decreases as B might be getting in and getting out
> > > > the cluster of A very frequently, then cache coherence ping-pong.
> > > >
> > >
> > > The counter argument can be that Task A and Task B are related and were
> > > running on the same cluster. But Load balancer moved Task B to a different
> > > cluster. Now this check may cause them to continue to run on two different
> > > clusters, even though the underlying load balance issues may have changed.
> > >
> > > No?
> >
> > LB is much slower than select_idle_cpu(). select_idle_cpu() can dynamically
> > work afterwards. so it is always a dynamic balance and task migration.
> >
> > >
> > >
> > > --
> > > Thanks and Regards
> > > Srikar Dronamraju
> >
> > Thanks
> > Barry
>
> --
Thanks
Barry
On Fri, Feb 4, 2022 at 11:28 PM Barry Song <[email protected]> wrote:
>
> On Fri, Feb 4, 2022 at 8:33 PM Srikar Dronamraju
> <[email protected]> wrote:
> >
> > * Barry Song <[email protected]> [2022-02-02 09:20:32]:
> >
> > > On Tue, Feb 1, 2022 at 10:39 PM Srikar Dronamraju
> > > <[email protected]> wrote:
> > > >
> > > > * Barry Song <[email protected]> [2022-01-28 07:40:15]:
> > > >
> > > > > On Fri, Jan 28, 2022 at 8:13 PM Srikar Dronamraju
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > * Barry Song <[email protected]> [2022-01-28 09:21:08]:
> > > > > >
> > > > > > > On Fri, Jan 28, 2022 at 4:41 AM Gautham R. Shenoy
> > > > > > > <[email protected]> wrote:
> > > > > > > >
> > > > > > > > On Wed, Jan 26, 2022 at 04:09:47PM +0800, Yicong Yang wrote:
> > > > > > > > > From: Barry Song <[email protected]>
> > > > > > > > >
> > > > > I am sorry I didn't get your question. Currently the code works as below:
> > > > > if task A wakes up task B, and task A is in LLC0 and task B is in LLC1.
> > > > > we will scan the cluster of A before scanning the whole LLC0, in this case,
> > > > > cluster of A is the closest sibling, so it is the better choice than other CPUs
> > > > > which are in LLC0 but not in the cluster of A.
> > > >
> > > > Yes, this is right.
> > > >
> > > > > But we do scan all cpus of LLC0
> > > > > afterwards if we fail to find an idle CPU in the cluster.
> > > >
> > > > However my reading of the patch, before we can scan other clusters within
> > > > the LLC (aka LLC0), we have a check in scan cluster which says
> > > >
> > > > /* Don't ping-pong tasks in and out cluster frequently */
> > > > if (cpus_share_resources(target, prev_cpu))
> > > > return target;
> > > >
> > > > My reading of this is, ignore other clusters (at this point, we know there
> > > > are no idle CPUs in this cluster. We don't know if there are idle cpus in
> > > > them or not) if the previous CPU and target CPU happen to be from the same
> > > > cluster. This effectively means we are given preference to cache over idle
> > > > CPU.
> > >
> > > Note we only ignore other cluster while prev_cpu and target are in same
> > > cluster. if the condition is false, we are not ignoring other cpus. typically,
> > > if waker is the target, and wakee is the prev_cpu, that means if they are
> > > already in one cluster, we don't stupidly spread them in select_idle_cpu() path
> > > as benchmark shows we are losing. so, yes, we are giving preference to
> > > cache over CPU.
> >
> > We already figured out that there are no idle CPUs in this cluster. So dont
> > we gain performance by picking a idle CPU/core in the neighbouring cluster.
> > If there are no idle CPU/core in the neighbouring cluster, then it does make
> > sense to fallback on the current cluster.
>
> What you suggested is exactly the approach we have tried at the first beginning
> during debugging. but we didn't gain performance according to benchmark, we
> were actually losing. that is why we added this line to stop ping-pong:
> /* Don't ping-pong tasks in and out cluster frequently */
> if (cpus_share_resources(target, prev_cpu))
> return target;
>
> If we delete this, we are seeing a big loss of tbench while system
> load is medium
> and above.
While one system has a high load, if we scan the neighbour clusters
after we fail to
get an idle cpu in the target. we can really successfully find an idle
cpu in neighbours
sometimes. There is no doubt of this. Our experiments have shown this is 100%
true. But the problem is that actually all cpus are very busy, so each
cpu gets a
very small idle time. After we migrate tasks to neighbours, shortly
the neighbour
clusters will be full of tasks, then the neighbours might kick their
tasks out afterwards.
so we will see tasks move all around many clusters like monkeys, then we don't
gain performance.
>
> >
> > >
> > > >
> > > > Or Am I still missing something?
> > > >
> > > > >
> > > > > After a while, if the cluster of A gets an idle CPU and pulls B into the
> > > > > cluster, we prefer not pushing B out of the cluster of A again though
> > > > > there might be an idle CPU outside. as benchmark shows getting an
> > > > > idle CPU out of the cluster of A doesn't bring performance improvement
> > > > > but performance decreases as B might be getting in and getting out
> > > > > the cluster of A very frequently, then cache coherence ping-pong.
> > > > >
> > > >
> > > > The counter argument can be that Task A and Task B are related and were
> > > > running on the same cluster. But Load balancer moved Task B to a different
> > > > cluster. Now this check may cause them to continue to run on two different
> > > > clusters, even though the underlying load balance issues may have changed.
> > > >
> > > > No?
> > >
> > > LB is much slower than select_idle_cpu(). select_idle_cpu() can dynamically
> > > work afterwards. so it is always a dynamic balance and task migration.
> > >
> > > >
> > > >
> > > > --
> > > > Thanks and Regards
> > > > Srikar Dronamraju
> > >
> > > Thanks
> > > Barry
> >
> > --
>
Thanks
Barry
On Fri, Feb 04, 2022 at 11:28:25PM +1300, Barry Song wrote:
> > We already figured out that there are no idle CPUs in this cluster. So dont
> > we gain performance by picking a idle CPU/core in the neighbouring cluster.
> > If there are no idle CPU/core in the neighbouring cluster, then it does make
> > sense to fallback on the current cluster.
>
> What you suggested is exactly the approach we have tried at the first beginning
> during debugging. but we didn't gain performance according to benchmark, we
> were actually losing. that is why we added this line to stop ping-pong:
> /* Don't ping-pong tasks in and out cluster frequently */
> if (cpus_share_resources(target, prev_cpu))
> return target;
>
> If we delete this, we are seeing a big loss of tbench while system
> load is medium
> and above.
Thanks for clarifying this Barry. Indeed, if the workload is sensitive
to data ping-ponging across L2 clusters, this heuristic makes sense. I
was thinking of workloads that require lower tail latency, in which
case exploring the larger LLC would have made more sense, assuming
that the larger LLC has an idle core/CPU.
In the absence of any hints from the workload, like something that
Peter had previous suggested
(https://lore.kernel.org/lkml/[email protected]/),
optimizing for cache-access seems to be the right thing to do.
>
> Thanks
> Barry
--
Thanks and Regards
gautham.