Re: Patch "sched/fair: sanitize vruntime of entity being placed" has been added to the 4.14-stable tree

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Mar 06, 2023 at 06:51:15PM +0800, Zhang Qiao wrote:
> 
> 
> 在 2023/3/6 18:05, Greg KH 写道:
> > On Mon, Mar 06, 2023 at 05:28:41PM +0800, Zhang Qiao wrote:
> >>
> >>
> >> 在 2023/3/6 17:19, Greg KH 写道:
> >>> On Mon, Mar 06, 2023 at 04:31:57PM +0800, Zhang Qiao wrote:
> >>>>
> >>>>
> >>>> 在 2023/3/5 12:02, Sasha Levin 写道:
> >>>>> This is a note to let you know that I've just added the patch titled
> >>>>>
> >>>>>     sched/fair: sanitize vruntime of entity being placed
> >>>>>
> >>>>> to the 4.14-stable tree which can be found at:
> >>>>>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> >>>>>
> >>>>> The filename of the patch is:
> >>>>>      sched-fair-sanitize-vruntime-of-entity-being-placed.patch
> >>>>> and it can be found in the queue-4.14 subdirectory.
> >>>>>
> >>>>> If you, or anyone else, feels it should not be added to the stable tree,
> >>>>> please let <stable@vger.kernel.org> know about it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> commit 38247e1de3305a6ef644404ac818bc6129440eae
> >>>>
> >>>> Hi,
> >>>> This patch has significant impact on the hackbench.throughput [1].
> >>>> Please don't backport this patch.
> >>>>
> >>>> [1] https://lore.kernel.org/lkml/202302211553.9738f304-yujie.liu@intel.com/T/#u
> >>>
> >>> This link says it made hackbench.throughput faster, not slower, so why
> >>> would we NOT want it?
> >>
> >> Please see this section. In some cases, this patch reset task's vruntime by mistake and
> >> will lead to wrong results.
> >>
> >>
> >> On Tue, Feb 21, 2023 at 03:34:16PM +0800, kernel test robot wrote:
> >>>
> >>> FYI, In addition to that, the commit also has significant impact on the following tests:
> >>>
> >>> +------------------+--------------------------------------------------+
> >>> | testcase: change | hackbench: hackbench.throughput -8.1% regression |
> >>> | test machine     | 104 threads 2 sockets (Skylake) with 192G memory |
> >>> | test parameters  | cpufreq_governor=performance                     |
> >>> |                  | ipc=socket                                       |
> >>> |                  | iterations=4                                     |
> >>> |                  | mode=process                                     |
> >>> |                  | nr_threads=100%                                  |
> >>> +------------------+--------------------------------------------------+
> >>>
> >>> Details are as below:
> > 
> > So one benchmark did better, by a lot, and one did less, by a little?
> > Which one matters "more">
> > 
> > So Linus's tree now has a regression?  Or not?  I'm confused.  We are
> 
> Yes, Linus's tree also has a regression, and i have sent a patch[1] for fix this regression.
> 
> 
> [1]: https://lore.kernel.org/lkml/79850642-ebac-5c23-d32d-b28737dcb91e@huawei.com/
> 
> thanks.
> Zhang qiao.

Ok, I've dropped this from all stable queues now.  Please let us know
when we can pick it up again and what the fixup commit id in Linus's
tree is when it lands there.

thanks,

greg k-h