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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx/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
just matching what is in Linus's tree, if it's wrong here, in a stable
tree, it should be wrong there too.  If not, please explain why not?

thanks,

greg k-h



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux