Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Sun, 26 Nov 2023 17:25:48 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Madadi Vineeth Reddy <vineethr@linux.ibm.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Ingo Molnar <mingo@redhat.com>,
        "Vincent Guittot" <vincent.guittot@linaro.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Tim Chen <tim.c.chen@intel.com>, Aaron Lu <aaron.lu@intel.com>,
        "Dietmar Eggemann" <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Mel Gorman <mgorman@suse.de>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        Chen Yu <yu.chen.surf@gmail.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/3] Introduce SIS_CACHE to choose previous CPU during
 task wakeup
Message-ID: <ZWMPHC+uWdojgDB3@chenyu5-mobl2.ccr.corp.intel.com>
References: <cover.1700548379.git.yu.c.chen@intel.com>
 <23e9a0f2-be96-4eb6-0242-2865180c1d6c@linux.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <23e9a0f2-be96-4eb6-0242-2865180c1d6c@linux.ibm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KPmTbCVDQS5BfOER0LXpm5q0s8UZFN6w8kG18tnZ0KXECCt7h7ITc6b8AbjX?=
 =?us-ascii?Q?Mzdx5rdenrf6FyQwUcROj5QEnOUb1OC3YXOrh8RJDhnGNXVj5VqqfDDJYnoF?=
 =?us-ascii?Q?/Amw9si0R/LL3RG9DBYuN1SaIZCEGAulzl63MaFLE/rx4nq4vs1beswtQnxe?=
 =?us-ascii?Q?n+U+SG7KRxGyFUgF9ggwTp2gbCyhyK7ZzLC/owto4hclynNmQh0yopaOO24F?=
 =?us-ascii?Q?pJ2hmbRP3mbhQvqVX/iby56u3B8f2WDz+lYoPZh6QwDq23N0r+HikauWIPBZ?=
 =?us-ascii?Q?eW7YB7DqG4Bb5Bv45snNkBET4D1rZmBhmGuNElfHtXrk7cpuYYGwZ9mvfLRE?=
 =?us-ascii?Q?LFkzBYkzjELoX6Ds2+D1IHHDuDs6zo8GWVXYWICLyxmFEnNdAwtURUaarhXx?=
 =?us-ascii?Q?ZDbjSi/St68McemjfrYyBFoVPiYeTooYSe214F30U2UPPtFAecfYrY9yH1Dy?=
 =?us-ascii?Q?SDmTZaNJ8ng9tvBL09+Kkws/AKsc40P2rTsTEWOAkYST05tQ6s24q6xu6AgV?=
 =?us-ascii?Q?SkS+NMRyctTfoc/rA5BmfXmhdXUIk5R+Zlmgl92zYLCMdnFACPIjKvMArnSW?=
 =?us-ascii?Q?07cGgv5JGOvKU3B7TqmdcqIJM1OWnObZTraRTm76nHK94ZfXpQhG4u/aQ2XU?=
 =?us-ascii?Q?3FY6qHS941LTTq/YwCEYNowqbLIR8JH2fXFVM8wuJUTUiXaGvozSr8ZjZ1rY?=
 =?us-ascii?Q?hxitVe2z67Ztk954y8yGRVqepEZIqlPe1Oi3OftTd7/sK+0eZux1fv7ayFzl?=
 =?us-ascii?Q?C1bpKeZ9NTDwLlk/ZLSyfaSrH+xRd5us1gLQjZm4Vedxs4fMUJRf+jL+8Qlm?=
 =?us-ascii?Q?Wje65lNGMuakMaJqSJ6Jf9P/8umR/bDJAfwAZXxphNKZ6sahu75KkWmcPAXv?=
 =?us-ascii?Q?rXEusvZcL4w/Ea24Ls8iXfz+Dd9t46/M/Y1qLam8rQmssH2vnWlvzSaZ/Z39?=
 =?us-ascii?Q?/1CS6yGvmx/L7PZtHb0JQWAQrLylz4e+N+980HB9n6x12WuxiK7/mBxqgVJI?=
 =?us-ascii?Q?ymsTIgHCs5ax45L+4nWVb7s14j38zuUNOwALNpZA03uHk5Y3rQUAea1oYHeU?=
 =?us-ascii?Q?XjO2M3pVZI+vU5ueQlEy9pK9Zs+hxkM2M8tH+p0RtgLpMIsdNu2x+c/VM6GM?=
 =?us-ascii?Q?1utF1CrRfZYWZx8lhc8eBV/lKHyAwAIzC1PxtV8lDOAFqCDZIioK9EOgFem3?=
 =?us-ascii?Q?NWiT3ZEnsyvYOyRx0RnbuCPU/m1Qr4Ijt3+qekudxZitl6HL9uX9b8tYP3dh?=
 =?us-ascii?Q?1dB+8eJnuhAYljtTfzCOFi3myvNcRvGAjl0qNy/rxWwUbpcR+6QZSzS1fVXF?=
 =?us-ascii?Q?+f7+16uOeEqro3jQpseosucKBguwyPCDH9riBXzVSDBHnHxgqAs9KuQKLZO0?=
 =?us-ascii?Q?Z0eW618qC/T9fvnQk2cW1+8QRcwZedb5doujCGknBEwjwd/x786DZfQM5dpf?=
 =?us-ascii?Q?3Hds6jOtUqm6qCABe8BuxvbJuTcSDQMKH3e802oCMy6NNju2qzBZLkKlERx5?=
 =?us-ascii?Q?g/kxGjDucv4brb5e1wBZZdVq/ijU6M2FwW5FqA86q7DE4M7kpZQpqDrwaeeI?=
 =?us-ascii?Q?ONXrzk6DuFLdKrnFhtJgEgInk6P/Nbx5iWfqpTim?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 47017963-6a29-40ad-c3be-08dbee61b72d
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Nov 2023 09:26:06.3403
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ys1JCPYJ+SxATCIL+luscWrkNi50Qwd3koIkt6ePSlftQ4VEF3x+cKts8rtze6j4SsFBFqWdeaLdpkr+vgEhMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7633
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Sun, 26 Nov 2023 01:26:56 -0800 (PST)

On 2023-11-26 at 14:14:20 +0530, Madadi Vineeth Reddy wrote:
> Hi Chen Yu,
> 
> On 21/11/23 13:09, Chen Yu wrote:
> > v1  -> v2:
> > - Move the task sleep duration from sched_entity to task_struct. (Aaron Lu)
> > - Refine the task sleep duration calculation based on task's previous running
> >   CPU. (Aaron Lu)
> > - Limit the cache-hot idle CPU scan depth to reduce the time spend on
> >   searching, to fix the regression. (K Prateek Nayak)
> > - Add test results of the real life workload per request from Ingo
> >     Daytrader on a power system. (Madadi Vineeth Reddy)
> >     OLTP workload on Xeon Sapphire Rapids.
> > - Refined the commit log, added Reviewed-by tag to PATCH 1/3
> >   (Mathieu Desnoyers).
> > 
> > RFC -> v1:
> > - drop RFC
> > - Only record the short sleeping time for each task, to better honor the
> >   burst sleeping tasks. (Mathieu Desnoyers)
> > - Keep the forward movement monotonic for runqueue's cache-hot timeout value.
> >   (Mathieu Desnoyers, Aaron Lu)
> > - Introduce a new helper function cache_hot_cpu() that considers
> >   rq->cache_hot_timeout. (Aaron Lu)
> > - Add analysis of why inhibiting task migration could bring better throughput
> >   for some benchmarks. (Gautham R. Shenoy)
> > - Choose the first cache-hot CPU, if all idle CPUs are cache-hot in
> >   select_idle_cpu(). To avoid possible task stacking on the waker's CPU.
> >   (K Prateek Nayak)
> > 
> > Thanks for the comments and tests!
> > 
> > ----------------------------------------------------------------------
> > 
> > This series aims to continue the discussion of how to make the wakee
> > to choose its previous CPU easier.
> > 
> > When task p is woken up, the scheduler leverages select_idle_sibling()
> > to find an idle CPU for it. p's previous CPU is usually a preference
> > because it can improve cache locality. However in many cases, the
> > previous CPU has already been taken by other wakees, thus p has to
> > find another idle CPU.
> > 
> > Inhibit the task migration could benefit many workloads. Inspired by
> > Mathieu's proposal to limit the task migration ratio[1], introduce
> > the SIS_CACHE. It considers the sleep time of the task for better
> > task placement. Based on the task's short sleeping history, tag p's
> > previous CPU as cache-hot. Later when p is woken up, it can choose
> > its previous CPU in select_idle_sibling(). When other task is
> > woken up, skip this cache-hot idle CPU and try the next idle CPU
> > when possible. The idea of SIS_CACHE is to optimize the idle CPU
> > scan sequence. The extra scan time is minimized by restricting the
> > scan depth of cache-hot CPUs to 50% of the scan depth of SIS_UTIL.
> > 
> > This test is based on tip/sched/core, on top of
> > Commit ada87d23b734
> > ("x86: Fix CPUIDLE_FLAG_IRQ_ENABLE leaking timer reprogram")
> > 
> > This patch set has shown 15% ~ 70% improvements for client/server
> > workloads like netperf and tbench. It shows 0.7% improvement of
> > OLTP with 0.2% run-to-run variation on Xeon 240 CPUs system.
> > There is 2% improvement of another real life workload Daytrader
> > per the test of Madadi on a power system with 96 CPUs. Prateek
> > has helped check there is no obvious microbenchmark regression
> > of the v2 on a 3rd Generation EPYC System with 128 CPUs.
> > 
> 
> Tested the patch on power system with 46 cores. Total of 368 CPU's.
> System has 8 NUMA nodes.
> 
> Below are some of the benchmark results.
> 
> schbench(new) 99.0th latency (lower is better)
> ========
> case            load        	baseline[pct imp](std%)       SIS_CACHE[pct imp]( std%)
> normal          1-mthreads      1.00 [ 0.00]( 4.34)            1.02 [ -2.00]( 5.98)
> normal          2-mthreads      1.00 [ 0.00]( 13.95)           1.08 [ -8.00]( 10.39)
> normal          4-mthreads      1.00 [ 0.00]( 6.20)            0.94 [ +6.00]( 10.90)
> normal          6-mthreads      1.00 [ 0.00]( 12.76)           1.03 [ -3.00]( 9.33)
> 
> It seems like schbench is not much impacted with this patch(The pct imp of schbench is within the std%).
> I expected some regression in wakeup latency while searching for an idle cpu which is not cache hot.
> But I guess limiting the search depth had helped.
>

I think so. Cutting the cache-hot cpu scan depth to 50% seems to also cure the regression
reported by Prateek.
 
> 
> producer_consumer avg time/access (lower is better)
> ========
> loads per consumer iteration   baseline[pct imp](std%)         SIS_CACHE[pct imp]( std%)
> 5                  		1.00 [ 0.00]( 0.00)            0.93 [ +7.00]( 4.77)
> 10                   		1.00 [ 0.00]( 0.00)            1.00 [  0.00]( 0.00)
> 20                    		1.00 [ 0.00]( 0.00)            1.00 [  0.00]( 0.00)
> 
> The main goal of the patch of improving cache locality is reflected as SIS_CACHE only improves in this workload, 
> when loads per consumer iteration is lower.
> 
> 
> hackbench normalized time in seconds (lower is better)
> ========
> case            load        baseline[pct imp](std%)         SIS_CACHE[pct imp]( std%)
> process-sockets 1-groups     1.00 [ 0.00]( 4.78)            0.99 [ +1.00]( 6.45)
> process-sockets 2-groups     1.00 [ 0.00]( 0.97)            1.02 [ -2.00]( 1.87)
> process-sockets 4-groups     1.00 [ 0.00]( 3.63)            1.01 [ -1.00]( 2.96)
> process-sockets 8-groups     1.00 [ 0.00]( 0.43)            1.00 [  0.00]( 0.27)
> process-pipe    1-groups     1.00 [ 0.00](23.77)            0.88 [+12.00](22.77)
> process-pipe    2-groups     1.00 [ 0.00]( 3.44)            1.03 [ -3.00]( 4.00)
> process-pipe    4-groups     1.00 [ 0.00]( 2.41)            0.98 [ +2.00]( 3.88)
> process-pipe    8-groups     1.00 [ 0.00]( 7.09)            1.07 [ -7.00]( 4.25)
> threads-pipe    1-groups     1.00 [ 0.00](18.47)            1.11 [-11.00](24.21)
> threads-pipe    2-groups     1.00 [ 0.00]( 6.45)            0.97 [ +3.00]( 5.58)
> threads-pipe    4-groups     1.00 [ 0.00]( 5.63)            0.96 [ +2.00]( 5.90)
> threads-pipe    8-groups     1.00 [ 0.00]( 1.65)            1.03 [ -3.00]( 3.97)
> threads-sockets 1-groups     1.00 [ 0.00]( 2.00)            1.00 [  0.00]( 0.65)
> threads-sockets 2-groups     1.00 [ 0.00]( 1.69)            1.02 [ -2.00]( 1.48)
> threads-sockets 4-groups     1.00 [ 0.00]( 5.66)            1.01 [ -1.00]( 3.56)
> threads-sockets 8-groups     1.00 [ 0.00]( 0.26)            0.99 [ +1.00]( 0.36)
> 
> hackbench is not impacted.
> 
> 
> Daytrader throughput (higher is better)
> ========
> instances,users                baseline[pct imp](std%)         SIS_CACHE[pct imp]( std%)
> 3,30                 		1.00 [ 0.00]( 2.30)            1.02 [ +2.00]( 1.64)
> 3,60                 		1.00 [ 0.00]( 0.55)            1.01 [ +1.00]( 1.41)
> 3,90                  		1.00 [ 0.00]( 1.20)            1.02 [ +2.00]( 1.04)
> 3,120                  		1.00 [ 0.00]( 0.84)            1.02 [ +2.00]( 1.02)
> 
> A real life workload like daytrader is benefiting slightly with this patch.
> 
> 
> Tested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
>

Thanks!

Best,
Chenyu 
> Thanks and Regards
> Madadi Vineeth Reddy