mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Rik van Riel <riel@surriel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 13/19] mm/migrate: Use xchg instead of spinlock
Date: Thu, 21 Jun 2018 10:51:12 +0100	[thread overview]
Message-ID: <20180621095111.md7m5jhxxoswnykf@techsingularity.net> (raw)
In-Reply-To: <1529514181-9842-14-git-send-email-srikar@linux.vnet.ibm.com>

On Wed, Jun 20, 2018 at 10:32:54PM +0530, Srikar Dronamraju wrote:
> Currently resetting the migrate rate limit is under a spinlock.
> The spinlock will only serialize the migrate rate limiting and something
> similar can actually be achieved by a simpler xchg.
> 
> Running SPECjbb2005 on a 4 node machine and comparing bops/JVM
> JVMS  LAST_PATCH  WITH_PATCH  %CHANGE
> 16    25804.1     25355.9     -1.73
> 1     73413       72812       -0.81
> 
> Running SPECjbb2005 on a 16 node machine and comparing bops/JVM
> JVMS  LAST_PATCH  WITH_PATCH  %CHANGE
> 8     101748      110199      8.30
> 1     170818      176303      3.21
> 
> (numbers from v1 based on v4.17-rc5)
> Testcase       Time:         Min         Max         Avg      StdDev
> numa01.sh      Real:      435.67      707.28      527.49       97.85
> numa01.sh       Sys:       76.41      231.19      162.49       56.13
> numa01.sh      User:    38247.36    59033.52    45129.31     7642.69
> numa02.sh      Real:       60.35       62.09       61.09        0.69
> numa02.sh       Sys:       15.01       30.20       20.64        5.56
> numa02.sh      User:     5195.93     5294.82     5240.99       40.55
> numa03.sh      Real:      752.04      919.89      836.81       63.29
> numa03.sh       Sys:      115.10      133.35      125.46        7.78
> numa03.sh      User:    58736.44    70084.26    65103.67     4416.10
> numa04.sh      Real:      418.43      709.69      512.53      104.17
> numa04.sh       Sys:      242.99      370.47      297.39       42.20
> numa04.sh      User:    34916.14    48429.54    38955.65     4928.05
> numa05.sh      Real:      379.27      434.05      403.70       17.79
> numa05.sh       Sys:      145.94      344.50      268.72       68.53
> numa05.sh      User:    32679.32    35449.75    33989.10      913.19
> 
> Testcase       Time:         Min         Max         Avg      StdDev 	 %Change
> numa01.sh      Real:      490.04      774.86      596.26       96.46 	 -11.5%
> numa01.sh       Sys:      151.52      242.88      184.82       31.71 	 -12.0%
> numa01.sh      User:    41418.41    60844.59    48776.09     6564.27 	 -7.47%
> numa02.sh      Real:       60.14       62.94       60.98        1.00 	 0.180%
> numa02.sh       Sys:       16.11       30.77       21.20        5.28 	 -2.64%
> numa02.sh      User:     5184.33     5311.09     5228.50       44.24 	 0.238%
> numa03.sh      Real:      790.95      856.35      826.41       24.11 	 1.258%
> numa03.sh       Sys:      114.93      118.85      117.05        1.63 	 7.184%
> numa03.sh      User:    60990.99    64959.28    63470.43     1415.44 	 2.573%
> numa04.sh      Real:      434.37      597.92      504.87       59.70 	 1.517%
> numa04.sh       Sys:      237.63      397.40      289.74       55.98 	 2.640%
> numa04.sh      User:    34854.87    41121.83    38572.52     2615.84 	 0.993%
> numa05.sh      Real:      386.77      448.90      417.22       22.79 	 -3.24%
> numa05.sh       Sys:      149.23      379.95      303.04       79.55 	 -11.3%
> numa05.sh      User:    32951.76    35959.58    34562.18     1034.05 	 -1.65%
> 
> Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

Acked-by: Mel Gorman <mgorman@techsingularity.net>

However, I'm actively considering removing rate limiting entirely. It
has been reported elsewhere that it was a limiting factor for some
workloads. When it was introduced, it was to avoid worst-case migration
storms but I believe that those ping-pong style problems should now be
ok.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2018-06-21  9:51 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 17:02 [PATCH v2 00/19] Fixes for sched/numa_balancing Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 01/19] sched/numa: Remove redundant field Srikar Dronamraju
2018-07-25 14:23   ` [tip:sched/core] " tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 02/19] sched/numa: Evaluate move once per node Srikar Dronamraju
2018-06-21  9:06   ` Mel Gorman
2018-07-25 14:24   ` [tip:sched/core] " tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 03/19] sched/numa: Simplify load_too_imbalanced Srikar Dronamraju
2018-07-25 14:24   ` [tip:sched/core] sched/numa: Simplify load_too_imbalanced() tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 04/19] sched/numa: Set preferred_node based on best_cpu Srikar Dronamraju
2018-06-21  9:17   ` Mel Gorman
2018-07-25 14:25   ` [tip:sched/core] " tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 05/19] sched/numa: Use task faults only if numa_group is not yet setup Srikar Dronamraju
2018-06-21  9:38   ` Mel Gorman
2018-07-25 14:25   ` [tip:sched/core] sched/numa: Use task faults only if numa_group is not yet set up tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 06/19] sched/debug: Reverse the order of printing faults Srikar Dronamraju
2018-07-25 14:26   ` [tip:sched/core] " tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 07/19] sched/numa: Skip nodes that are at hoplimit Srikar Dronamraju
2018-07-25 14:27   ` [tip:sched/core] sched/numa: Skip nodes that are at 'hoplimit' tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 08/19] sched/numa: Remove unused task_capacity from numa_stats Srikar Dronamraju
2018-07-25 14:27   ` [tip:sched/core] sched/numa: Remove unused task_capacity from 'struct numa_stats' tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 09/19] sched/numa: Modify migrate_swap to accept additional params Srikar Dronamraju
2018-07-25 14:28   ` [tip:sched/core] sched/numa: Modify migrate_swap() to accept additional parameters tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 10/19] sched/numa: Stop multiple tasks from moving to the cpu at the same time Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 11/19] sched/numa: Restrict migrating in parallel to the same node Srikar Dronamraju
2018-07-23 10:38   ` Peter Zijlstra
2018-07-23 11:16     ` Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 12/19] sched/numa: Remove numa_has_capacity Srikar Dronamraju
2018-07-25 14:28   ` [tip:sched/core] sched/numa: Remove numa_has_capacity() tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 13/19] mm/migrate: Use xchg instead of spinlock Srikar Dronamraju
2018-06-21  9:51   ` Mel Gorman [this message]
2018-07-23 10:54   ` Peter Zijlstra
2018-07-23 11:20     ` Srikar Dronamraju
2018-07-23 14:04       ` Peter Zijlstra
2018-06-20 17:02 ` [PATCH v2 14/19] sched/numa: Updation of scan period need not be in lock Srikar Dronamraju
2018-06-21  9:51   ` Mel Gorman
2018-07-25 14:29   ` [tip:sched/core] sched/numa: Update the scan period without holding the numa_group lock tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 15/19] sched/numa: Use group_weights to identify if migration degrades locality Srikar Dronamraju
2018-07-25 14:29   ` [tip:sched/core] " tip-bot for Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 16/19] sched/numa: Detect if node actively handling migration Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 17/19] sched/numa: Pass destination cpu as a parameter to migrate_task_rq Srikar Dronamraju
2018-06-20 17:02 ` [PATCH v2 18/19] sched/numa: Reset scan rate whenever task moves across nodes Srikar Dronamraju
2018-06-21 10:05   ` Mel Gorman
2018-07-04 11:19     ` Srikar Dronamraju
2018-06-20 17:03 ` [PATCH v2 19/19] sched/numa: Move task_placement closer to numa_migrate_preferred Srikar Dronamraju
2018-06-21 10:06   ` Mel Gorman
2018-07-25 14:30   ` [tip:sched/core] sched/numa: Move task_numa_placement() closer to numa_migrate_preferred() tip-bot for Srikar Dronamraju
2018-06-20 17:03 ` [PATCH v2 00/19] Fixes for sched/numa_balancing Srikar Dronamraju
2018-07-23 13:57 ` Peter Zijlstra
2018-07-23 15:09   ` Srikar Dronamraju
2018-07-23 15:21     ` Peter Zijlstra
2018-07-23 16:29       ` Srikar Dronamraju
2018-07-23 16:47         ` Peter Zijlstra
2018-07-23 15:33     ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180621095111.md7m5jhxxoswnykf@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®