Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
* Peter Zijlstra wrote:
> On Sun, Oct 04, 2020 at 05:21:08PM +0100, Mel Gorman wrote:
> > On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to
> > > commit:
> > >
> > >
> > > commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> > > meaningless imbalance calculation")
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > >
> >
> > This commit was the start of a series that made large changes to load
> > balancing. The series was not bisect-safe and has since been reconciled
> > with the NUMA balancing. Any workload with a potential load balancing
> > problem has to be checked against the latest kernel to see if the problem
> > persists there. If it does, then tip/sched/core should be checked or
> > 5.10-rc1 when it comes out as tip has a few more LB changes pending.
>
> What Mel said ;-)
Basically it would be nice to test either the following commit directly
(which is the latest relevant sched/core commit):
233e7aca4c8a: ("sched/fair: Use dst group while checking imbalance for NUMA
balancer")
Or a -next version that includes these commits.
Thanks,
Ingo
Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
On Mon, 5 Oct 2020 at 08:50, Peter Zijlstra wrote:
>
> On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to
> > commit:
> >
> >
> > commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> > meaningless imbalance calculation")
>
> This is the middle of a series that reworks the load balancer. Does this
> regression still exist at the end of it?
>
> Which would be around:
>
> 57abff067a08 ("sched/fair: Rework find_idlest_group()")
>
> or possible a little later, Vincent?
I would consider 6cf82d559e1a ("sched/cfs: fix spurious active migration")
But even then, some fixes have been added. Mel perfectly described that
Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
On Sun, Oct 04, 2020 at 05:21:08PM +0100, Mel Gorman wrote:
> On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to
> > commit:
> >
> >
> > commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> > meaningless imbalance calculation")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
>
> This commit was the start of a series that made large changes to load
> balancing. The series was not bisect-safe and has since been reconciled
> with the NUMA balancing. Any workload with a potential load balancing
> problem has to be checked against the latest kernel to see if the problem
> persists there. If it does, then tip/sched/core should be checked or
> 5.10-rc1 when it comes out as tip has a few more LB changes pending.
What Mel said ;-)
Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to commit:
>
>
> commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> meaningless imbalance calculation")
This is the middle of a series that reworks the load balancer. Does this
regression still exist at the end of it?
Which would be around:
57abff067a08 ("sched/fair: Rework find_idlest_group()")
or possible a little later, Vincent?
Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to commit:
>
>
> commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> meaningless imbalance calculation")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
This commit was the start of a series that made large changes to load
balancing. The series was not bisect-safe and has since been reconciled
with the NUMA balancing. Any workload with a potential load balancing
problem has to be checked against the latest kernel to see if the problem
persists there. If it does, then tip/sched/core should be checked or
5.10-rc1 when it comes out as tip has a few more LB changes pending.
--
Mel Gorman
SUSE Labs
