在 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%3Ba=su...
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
Thanks. Zhang Qiao.
Author: Zhang Qiao zhangqiao22@huawei.com Date: Mon Jan 30 13:22:16 2023 +0100
sched/fair: sanitize vruntime of entity being placed
[ Upstream commit 829c1651e9c4a6f78398d3e67651cef9bb6b42cc ] When a scheduling entity is placed onto cfs_rq, its vruntime is pulled to the base level (around cfs_rq->min_vruntime), so that the entity doesn't gain extra boost when placed backwards. However, if the entity being placed wasn't executed for a long time, its vruntime may get too far behind (e.g. while cfs_rq was executing a low-weight hog), which can inverse the vruntime comparison due to s64 overflow. This results in the entity being placed with its original vruntime way forwards, so that it will effectively never get to the cpu. To prevent that, ignore the vruntime of the entity being placed if it didn't execute for much longer than the characteristic sheduler time scale. [rkagan: formatted, adjusted commit log, comments, cutoff value] Signed-off-by: Zhang Qiao zhangqiao22@huawei.com Co-developed-by: Roman Kagan rkagan@amazon.de Signed-off-by: Roman Kagan rkagan@amazon.de Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Link: https://lkml.kernel.org/r/20230130122216.3555094-1-rkagan@amazon.de Signed-off-by: Sasha Levin sashal@kernel.org
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 3ff60230710c9..afa21e43477fa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3615,6 +3615,7 @@ static void place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) { u64 vruntime = cfs_rq->min_vruntime;
- u64 sleep_time;
/* * The 'current' period is already promised to the current tasks, @@ -3639,8 +3640,18 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) vruntime -= thresh; }
- /* ensure we never gain time by being placed backwards. */
- se->vruntime = max_vruntime(se->vruntime, vruntime);
- /*
* Pull vruntime of the entity being placed to the base level of
* cfs_rq, to prevent boosting it if placed backwards. If the entity
* slept for a long time, don't even try to compare its vruntime with
* the base as it may be too far off and the comparison may get
* inversed due to s64 overflow.
*/
- sleep_time = rq_clock_task(rq_of(cfs_rq)) - se->exec_start;
- if ((s64)sleep_time > 60LL * NSEC_PER_SEC)
se->vruntime = vruntime;
- else
se->vruntime = max_vruntime(se->vruntime, vruntime);
} static void check_enqueue_throttle(struct cfs_rq *cfs_rq); .
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%3Ba=su...
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?
confused,
greg k-h
在 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%3Ba=su...
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:
Thanks. Zhang Qiao.
confused,
greg k-h .
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%3Ba=su...
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 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
在 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%3Ba=su...
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.
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 .
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%3Ba=su...
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.
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
在 2023/3/7 23:23, Greg KH 写道:
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%3Ba=su... > > 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.
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.
Hi,
The fixup patch has been merged into Linus's tree, its commit id is: a53ce18cacb477dd0513c607f187d16f0fa96f71 ("sched/fair: Sanitize vruntime of entity being migrated")
thanks, Zhangqiao.
thanks,
greg k-h .
On Tue, Mar 28, 2023 at 05:02:21PM +0800, Zhang Qiao wrote:
在 2023/3/7 23:23, Greg KH 写道:
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%3Ba=su... >> >> 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.
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.
Hi,
The fixup patch has been merged into Linus's tree, its commit id is: a53ce18cacb477dd0513c607f187d16f0fa96f71 ("sched/fair: Sanitize vruntime of entity being migrated")
Wonderful, I have queued both of these up now, thank you for letting me know.
greg k-h
linux-stable-mirror@lists.linaro.org