Date:   Thu, 16 Mar 2023 19:13:15 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Yicong Yang <yangyicong@huawei.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Juri Lelli <juri.lelli@redhat.com>, <yangyicong@hisilicon.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Tim Chen <tim.c.chen@intel.com>,
        "Dietmar Eggemann" <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        Abel Wu <wuyun.abel@bytedance.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        Honglei Wang <wanghonglei@didichuxing.com>,
        "Len Brown" <len.brown@intel.com>,
        Chen Yu <yu.chen.surf@gmail.com>,
        Tianchen Ding <dtcccc@linux.alibaba.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Josh Don <joshdon@google.com>, Hillf Danton <hdanton@sina.com>,
        kernel test robot <yujie.liu@intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@intel.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 0/2] sched/fair: Wake short task on current CPU
Message-ID: <ZBL5y9gCJxvI4HW6@chenyu5-mobl1>
References: <cover.1677069490.git.yu.c.chen@intel.com>
 <718acf0e-2c98-cff3-98f4-da43d49f776b@huawei.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <718acf0e-2c98-cff3-98f4-da43d49f776b@huawei.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2gpCQgTjD2pdhgQ5e9sb6fNyI7RLi/JBcKkIPFlZx/vra+o8fHujx6M/QkZ9?=
 =?us-ascii?Q?amoRmDuFPkUVCjC6YBKpN6WpNMQsjlhIjnBDyLPEA744YpJZxqDlalMnGXeV?=
 =?us-ascii?Q?OPzLfAVRV+8qas8mB8PJ2RVQ/N6myw3th7Rh7eKB/rbqksLqW2m/a38ZxCa6?=
 =?us-ascii?Q?ZoR2+lzHwAHyT/exgtvQ4lYwo4LgsbxK2DoRTFVOB4eg2OBfXXXwPSVuicDS?=
 =?us-ascii?Q?+Q13LAhTZSQCPbgPg/n7GS+IcuE7DxbJw2R5U3Sa6kP83HZAyujAJbfsLBbP?=
 =?us-ascii?Q?6KwJifXu2OUs7hcTNTHA/yO+GiLppanGc8aViodOR/HX5M8y7R+Czn0eSmOR?=
 =?us-ascii?Q?/PtbKHroDPQP8aIb6JHQ2NrgDIuOHr3uroOywmfLjk+3Ho8pdjX0/OQ3vbCr?=
 =?us-ascii?Q?jcAMnDWZAaxu7JFhKMJCQyfvPabxBqjAf8M1ptrGVRU5SZhSTsSebDVSg6fy?=
 =?us-ascii?Q?Gl3+WNabPlUMx8mmEEbIIiL8pAyIu7NC7N+qH8hhJ7HLTOnntcAvqn30B3+T?=
 =?us-ascii?Q?o1zHlLVybwb7tduX2Q/2nykUoXKaUdompJRupgYlnQ5ycxohBPyj+nrizTLP?=
 =?us-ascii?Q?4cERVF/nwc/071coEMn6c653ecHHV2aPAO4OZRPcQlTJVuxkdY/2v+ASBaIB?=
 =?us-ascii?Q?wwzWoGSnPqWt4rDmpQedHsEbUSMefiGw059PAyyTG8knm6UT9H+46Tnq6Nd1?=
 =?us-ascii?Q?9V+9szqVtHKudDxg2eF8VJNN29v22gQHvjvUs7tg9z/4kUELmROHkUQnGh8A?=
 =?us-ascii?Q?Po4TnDTvEYazRbKbQ2lCTGIsDvuC3DrQEaLgDGpyuOw+fo0xG7LtZIn/DEqv?=
 =?us-ascii?Q?80GpW+sDQb3tM24t3MxGV4IN6uIk8/vQtyCJP0kGcwJ8UzIb7vyXmW9My0Zf?=
 =?us-ascii?Q?eXCc1Zn3A/GKXfHRKYYITjzJexBRjbfZTxr/s/igLErrMqe15y5nw73kPYjk?=
 =?us-ascii?Q?h66tvmSTWNKNXDGxKJd4QFsBN+oipuE63dQdZ+3gZz5wOTCnTfYo4JbNRBHk?=
 =?us-ascii?Q?yTmmdw0JckaF38FtXOpkIec9RtpquzT9X55lBXLiRPCuTTKe/Ojurl1MUfCn?=
 =?us-ascii?Q?c/6STXOv7mZl4GCwaSciuw2H5mnMJS5HAxwGXF4G5r/+A7XGBCVYk9NdxgNf?=
 =?us-ascii?Q?duqen0LXnY7yCd6aYyjk5Fz5x0X3O2voaOVrLQxT6S/jPiR/0QBLypP8+Wl5?=
 =?us-ascii?Q?grKObWHttp1iZzHqVcjK/CwgrFuVWKyqFg/yiaZtSZAHaxcOJpWhHb/AoSHE?=
 =?us-ascii?Q?spblw0Im8I6/1p65oA1mNWjnQ057jq+MjuaaEhbIeFLnBj0GTOuls21N6nBv?=
 =?us-ascii?Q?fI7ZBVXY84kIazpPjfUdOlkoTzX16Jl0j05tAtiDIeA6vZ+PX/soGYAFILHP?=
 =?us-ascii?Q?kCj373cw4umRQbwXnZe8aFeLMUC0dmVxwm+XExHcq3NVhCXcGM2o496fK/Op?=
 =?us-ascii?Q?WIiAn66TJSUmIKgkSIPR6CVx8Lw5nk4tlh4ofmkU5qFe+3zAauilZDV6tlH8?=
 =?us-ascii?Q?ZdyEFwXrxqXDcJxl0qW65JB9ibva0yXYcdI2AtDh3q6GqK0srwJ3s2w7TrXg?=
 =?us-ascii?Q?NZr40jwX2uDtAMrDIUqGYzsErkxO2ZWaY7DMZXq2?=
X-MS-Exchange-CrossTenant-Network-Message-Id: ee6f4fc1-69d0-4db9-7f8e-08db260f7b6e
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2023 11:13:34.2292
 (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: pAeaglkfeh5XuaRi4ODWqroan63v72v8sftBOwkM2neWhpVKe78JKQagKvsfNRAaQNpcF6NRsXUkd2pmrpRg5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5918
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2023-03-15 at 17:34:43 +0800, Yicong Yang wrote:
> Hi Chenyu,
> 
> On 2023/2/22 22:09, Chen Yu wrote:
> > The main purpose is to avoid too many cross CPU wake up when it is
> > unnecessary. The frequent cross CPU wake up brings significant damage
> > to some workloads, especially on high core count systems.
> > 
> > Inhibits the cross CPU wake-up by placing the wakee on waking CPU,
> > if both the waker and wakee are short-duration tasks. The short
> > duration task could become a trouble maker on high-load system,
> > because it could bring frequent context switch. This strategy
> > only takes effect when the system is busy. Because it is unreasonable
> > to inhibit the idle CPU scan when there are still idle CPUs.
> > 
> > First, introduce the definition of a short-duration task. Then
> > leverages the first patch to choose a local CPU for wakee.
> > 
> > Overall there is performance improvement on some overloaded case.
> > Such as will-it-scale, netperf. And no noticeable impact on
> > schbench, hackbench, tbench and a OLTP workload with a commercial
> > RDBMS, tested on a Intel Xeon 2 x 56C machine.
> > 
> > Per the test on Zen3 from Prateek, most benchmarks result saw small
> > wins or are comparable to sched:tip. SpecJBB Critical-jOps improved while
> > Max-jOPS saw a small hit, but it might be in the expected range.
> > ycsb-mongodb saw small uplift in NPS1 mode.
> > 
> > Throughput improvement of netperf(localhost) was observed on a
> > Rome 2 x 64C machine, when the number of clients equals the CPUs.
> > 
> > Abel reported against a latency regression from Redis on an overloaded
> > system. Inspired by his description, v5 added the check of wakee_flips
> > to mitigate task stacking.
> > 
> > Changes since v5:
> > 1. Check the wakee_flips of the waker/wakee. If the wakee_flips
> >    of waker/wakee are both 0, it indicates that the waker and the wakee
> >    are waking up each other. In this case, put them together on the
> >    same CPU. This is to avoid that too many wakees are stacked on
> >    one CPU, which might cause regression on redis.
> > 
> 
> The patch looks good to me. And for the v6 version there's no significant
> regression on our server. :)
> 
> Detailed results below. The setup are the same as what used on v4. There're
> some gain for UDP_RR. For mysql no significant regression, there're ~2%
> loss for 128 threads case but the proportion is within the fluctuation
> range so it should be ok.
>
Thanks Yicong for the test!

thanks,
Chenyu