Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Date:   Thu, 28 Sep 2023 16:41:10 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     K Prateek Nayak <kprateek.nayak@amd.com>
CC:     David Vernet <void@manifault.com>, <linux-kernel@vger.kernel.org>,
        <peterz@infradead.org>, <mingo@redhat.com>,
        <juri.lelli@redhat.com>, <vincent.guittot@linaro.org>,
        <dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
        <bsegall@google.com>, <mgorman@suse.de>, <bristot@redhat.com>,
        <vschneid@redhat.com>, <tj@kernel.org>, <roman.gushchin@linux.dev>,
        <gautham.shenoy@amd.com>, <aaron.lu@intel.com>,
        <wuyun.abel@bytedance.com>, <kernel-team@meta.com>
Subject: Re: [RFC PATCH 3/3] sched/fair: Add a per-shard overload flag
Message-ID: <ZRU8Jt1TzOD2pOxx@chenyu5-mobl2.ccr.corp.intel.com>
References: <31aeb639-1d66-2d12-1673-c19fed0ab33a@amd.com>
 <20230831104508.7619-1-kprateek.nayak@amd.com>
 <20230831104508.7619-4-kprateek.nayak@amd.com>
 <20230831191103.GC531917@maniforge>
 <258c9412-445a-04f5-dd0d-1f6699a257b6@amd.com>
 <ZRPS0cQo0/XcbkOj@chenyu5-mobl2.ccr.corp.intel.com>
 <d755d515-e5d6-b3fc-f7f5-9f8aebcf913a@amd.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d755d515-e5d6-b3fc-f7f5-9f8aebcf913a@amd.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?hesAEWAy70ljHnQRb6eXOCefqcd0ZPFKm6nJVmpDhQB9VHv6yBRdhbRy7K6c?=
 =?us-ascii?Q?GZObxIr3cnmd0CUPy6p1JEUn+YYhACxmyYpBalNFeY1rKmDrpuBvER5UUrjh?=
 =?us-ascii?Q?SiNURL7cFaje0yH3ioFTEpD5cxvIpPiFdIgWEPYQZybXeBFo75hJct0HRAyl?=
 =?us-ascii?Q?bJA7LbZAG6v+pvlu8qsVigf2s5HMT2NPn/Cokz8V3Mm1k2pLWKmUxiphODZ2?=
 =?us-ascii?Q?VuC7MEtYxwRsNkbFrulpEf39IWeE8z4jdXvJUCxq/Jt9oZDqsmCzfuVZnzVz?=
 =?us-ascii?Q?DTy5CIQFno30CNuwl0iYkT5S2b7THx53gugiL0Fsfm8r1+RFVdt5uAN0h4dh?=
 =?us-ascii?Q?KCaeTlVXkDN1OdUUeIZGrnT7hv/+HdR+pRzTCQS2BJdJGhMPgWdw5hNmPC0h?=
 =?us-ascii?Q?7uGle9WAl7HHSx+Bfb5l3H/XA/N/R8Yvwxc0Pj9+fvyaZz5hjWA/j6psjB93?=
 =?us-ascii?Q?teKlXVFFRCDhELrCMhVK1WRNZcsjWeYNwSlB2ERE7sCeBUmBuj4N2mpTEMQ8?=
 =?us-ascii?Q?4KSXLZGZYx61QPBKys14wRbQndiL0C4+N4puFgimdlAWnrKXmU6nGcvhbXqK?=
 =?us-ascii?Q?cHEjdRfe53p63HqRVnmxnNHK8huSoDLRYhp4S6A/3lO3JHaJfgL6plbMud8i?=
 =?us-ascii?Q?Z60ID9858JcSPouAR9y7Ob/Fhgx5FiSjDaSp4XfBhRjDwxI4IeeBhjM5n9kf?=
 =?us-ascii?Q?SUVspNvBFkZHXR8MbQPeam2M+iHGae/WAk/HkMr8BEvkoSyw8xFR2Y5anFDJ?=
 =?us-ascii?Q?RA+9GRvSVR7D0SgXBQbmii24x5k6Q5eqMVWqwRZdM78FiBWvbgeiKgF1QEVd?=
 =?us-ascii?Q?4+wFW1b4M4ccmyqEhcANdNKDPNwz4xF1piIPeh9OG5iVb49pg7/70TsCGk+m?=
 =?us-ascii?Q?UctWYlX/Fq2alDA6crtXBFOUu72OVEwO8QfAuEVOGtOTi7Vah4W/QzfNyQqv?=
 =?us-ascii?Q?8b3O8zka9cC+1PF4n4JnkE80ipgA5MjypoA0zM9NSzZkRemELESL5f00fbqv?=
 =?us-ascii?Q?QuDZMiP1a7wiQnDcp+YejXzKNf/hCK17P2gWH5qKnk9b6MmeOSiRp5XD4Lyw?=
 =?us-ascii?Q?2YQMa2LUB3IfHXlhnIjwvqMuOWlw7ieYebc6puf9eao4IL1Y/rTdZ+nbLiUu?=
 =?us-ascii?Q?Bf2fdHZ9phZwsPaRrLIpW3OG+A3mXUBMMITCDfhQ3dQD7dkA/BwySl83tgIp?=
 =?us-ascii?Q?yfAVXB50iw4do9SAPtc6A8zmXulqag/NGMD9yJTi1/1gaX2+ZMNWimjqDaKw?=
 =?us-ascii?Q?LU+tPlrV/Vc4d9tnfmeRSxfa3KBcIDu2m/SW59DoRIMr7zRGj7NCFlTn79Fr?=
 =?us-ascii?Q?3RCiDiroLDcVoCreLbQEGn9HGLJef52h/LHtntrIEQbj2hsbsap+vVgnuGal?=
 =?us-ascii?Q?KX0E6dBes8ptvYOG9Tfmhni0AZs+wwi0Ei8sRRyFcQnVwj3TGcnm0xSOBZaF?=
 =?us-ascii?Q?FKXv/n2leCjEKDG6UVdkwSxDn5d5HieNzmoszf0kA+rpkReN/bm6yaHgHPWV?=
 =?us-ascii?Q?N099i9Ooi1M9dr+SxqG4Hknm7CEKvP+d9WDsimtvDwSj5eFjmLbAhM+sit8k?=
 =?us-ascii?Q?exjIo4P8m56yksrEMdJM6L3mwnyNEpGq2hBaVvmH?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 51b93546-ddc2-4214-531c-08dbbffeb422
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2023 08:41:26.9231
 (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: vLAXmaagKffDRnt+drm+E1DQgv5Yafi5m9fN08Z63F2V+J/iMDqL0wRXcB/bIFgh48R/oAM92kyoxoQqhHZLmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7800
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 autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.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 (morse.vger.email [0.0.0.0]); Thu, 28 Sep 2023 01:41:51 -0700 (PDT)

On 2023-09-27 at 14:06:41 +0530, K Prateek Nayak wrote:
> Hello Chenyu,
> 
> On 9/27/2023 12:29 PM, Chen Yu wrote:
> > Hi Prateek,
> > 
> > On 2023-09-27 at 09:53:13 +0530, K Prateek Nayak wrote:
> >> Hello David,
> >>
> >> Some more test results (although this might be slightly irrelevant with
> >> next version around the corner)
> >>
> >> On 9/1/2023 12:41 AM, David Vernet wrote:
> >>> On Thu, Aug 31, 2023 at 04:15:08PM +0530, K Prateek Nayak wrote:
> >>>

[snip]

> > This makes me wonder if we can let shared_runq skip the C/S tasks.
> > The question would be how to define C/S tasks. At first thought:
> > A only wakes up B, and B only wakes up A, then they could be regarded as a pair
> > of C/S
> >  (A->last_wakee == B && B->last_wakee == A &&
> >   A->wakee_flips <= 1 && B->wakee_flips <= 1)
> > But for netperf/tbench, this does not apply, because netperf client leverages kernel
> > thread(workqueue) to wake up the netserver, that is A wakes up kthread T, then T
> > wakes up B. Unless we have a chain, we can not detect this wakeup behavior.
> 
> Yup, unless we have a notion of chain/flow, or until we can somehow
> account the wakeup of client using the kthread to the server, this will
> be hard to detect.
> 
> I can give it a try with the SIS_PAIR condition you shared above. Let
> me know.

Thanks Krateek, but I don't think SIS_PAIR could bring benefit to the netperf/tbench
since SIS_PAIR can not detect the chain wakeup.

thanks,
Chenyu