Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Message-ID: <a95bab2c-7f7a-18a2-6307-ffcdef4e2726@amd.com>
Date:   Mon, 6 Nov 2023 12:36:28 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.1
Subject: Re: [RFC PATCH v2 0/2] sched/fair migration reduction features
Content-Language: en-US
To:     Chen Yu <yu.c.chen@intel.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Swapnil Sapkal <Swapnil.Sapkal@amd.com>,
        Aaron Lu <aaron.lu@intel.com>, Tim Chen <tim.c.chen@intel.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>, x86@kernel.org
References: <20231019160523.1582101-1-mathieu.desnoyers@efficios.com>
 <85b710a9-5b26-b0df-8c21-c2768a21e182@amd.com>
 <ZUh/LK4iy3ukVaCn@chenyu5-mobl2.ccr.corp.intel.com>
From:   K Prateek Nayak <kprateek.nayak@amd.com>
In-Reply-To: <ZUh/LK4iy3ukVaCn@chenyu5-mobl2.ccr.corp.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NkVjejRSL1h1VnBtYVM5K3NIT0l4S1J5d3AxdFhTWEYzalMvTnhiQWY2RitT?=
 =?utf-8?B?akRwQk9hYVZDK0NVUVMrL1NCQjJhcW1EVXdnbnowVWZIQldyN1ZKbVptZU5y?=
 =?utf-8?B?KzBIanFZNlZOeGN2a3pZSEpZZGhDSzhGWlc2Qy8xK3dOcExSN01iVk04RlBK?=
 =?utf-8?B?UHBUeE5rZmJrczhwZHRDc1FIUHZQajZPMzJVWGoydDdud3p2VTQ5V0tITWFp?=
 =?utf-8?B?b1BFQmxta1IvaEVuTzBXY21oTVIrRDM2M3ZLOWZqWTRlOHhNaEI5dHhORFk5?=
 =?utf-8?B?U1g0STZyb1ZXSTE0akJUaDBtZjl0bUZyU2tyUDRUM2hSZ0g0ODd2YVo5VjVy?=
 =?utf-8?B?NUR5aW44NGx3QUtmTWRjdG9jdzZWQ09YWFdBek1wczU2OHpGZDVjMlMrempx?=
 =?utf-8?B?OGp1Q3pjNHJOT3M4WnNRTTNocXBydXY5bGx2RVlkODZuK1ZUdkpHOG1wRnZK?=
 =?utf-8?B?VFlERjE5S3JMS25LQVFuWCtkRTBQbktlVDgvRXNEQ2JtQUJBd20ybEIzVFJG?=
 =?utf-8?B?cm5BQWVmR3dseWc4QlhGK21SdllPd2V6TXZ5Tit5NzdTS3czMGVJVXRHeVU2?=
 =?utf-8?B?WklXM2IvbEhPYkZwVDYrTnJ3bzFkUnl6ZnlhbjJZa0lzTDJ4VThSUVZudzNC?=
 =?utf-8?B?WXFSMElGTC9DdjRpVXpYdU03cVpJTHNQbHZlRUV2UjZsNy9sNU0vbk5iWW5P?=
 =?utf-8?B?OWQ1RGdmWFJnQkdKUXJWeWRkUG5FaGJUaVd6d2pMWjdvNU1jY0U3SXQvaHJB?=
 =?utf-8?B?NVVHZ3QvZGR2R1o0dmN0L3lGMXZoM0JxaTFvcllGeW1IY3NPYUppNFdHOVhh?=
 =?utf-8?B?TXJTdUE5ZHJROHRaVURNOWFBS3VMSnBFeFNJcUxwSzZKTWYyZjlCQzRZaENG?=
 =?utf-8?B?TlU2Ni9odGxUU2FjRlRscnJWY3l2TjQ1U1ZjLzh5bm1QMWdFNUtlNlR0Z3k3?=
 =?utf-8?B?UXlHQVhmWDZscUVSdUwvSG1QbEJIa0pRbUlwQXUyeTY3NnFVME81Z2JuT2ts?=
 =?utf-8?B?SzJNQnpqSGd3QUJET2puZ1pCZzBoQk9NYnphd0pGa3A1NlV4YTJFdDBTT0Ri?=
 =?utf-8?B?bEhOQklXNnozOG45NGxKNUdYZkw2MHJOeWxRMUZ1dCs5N0NQM1Q1N3IrblI3?=
 =?utf-8?B?azA5aGVMamc4MkhFUjF2V1V3V1N3MUNMclhra1hOV2x0Qjlac3hKRUpNM080?=
 =?utf-8?B?UzFWZVNpMHhtUHB2YmhjT0JBNHppalhIUDhPamdHaDVybTJhaDMzUllYUzB2?=
 =?utf-8?B?K0xNaUJDZFN2N1l3TTZqU2RyU0k4ekVUbEQ3bmdyczBsTVhOQnlyQ2Q0SXNp?=
 =?utf-8?B?Nk9tMHNwZXVpdjI4TXorSFRMSTVSVVlwU1FJRnJ1eHp1eXpobjgxL3lTUzFV?=
 =?utf-8?B?YThud1ZCc3ZIcWRpdnRTN3U3bnVrckhOZ1dOcTRUOTNHWUZ4eWlCVVBwMWFI?=
 =?utf-8?B?MG9vZmNwemoyM2JTOERvVUpxVEpOSHJaZy90SDBDUjlvaVVOUzhEZ2VOSi8r?=
 =?utf-8?B?Y245WU41dnFSRGVQL2d3SGlycXkrUHc3YXZGM2VPKzJnY1o0MTV6cFBRdnFq?=
 =?utf-8?B?OVlUbElDTzExVlY3WWpPNkFoRDM3UUd5SDdHZlQ2bU1VUFhRdldrV0Vhb3Bu?=
 =?utf-8?B?elp5ZXdJajJ6U1prelBEblB3cTc0R3BuZjFWclhFVVh6Q1ltZGlERWloUXBR?=
 =?utf-8?B?VGZTL0dzTFBHZzVjRFN4S3lTUVVUWlNpamxqQTZubFdMc0ZKRUlleVZkM0J1?=
 =?utf-8?B?TnYrdU1YTnk1ak9BZy9xZjlEUmJEV0N6NnJUNmM3N3JndlZRUk5TaXdubnBm?=
 =?utf-8?B?cHRuWHhOOG5nNWNodDdETnE0KytmSTRhRkZqbkk5NXBWdFJjZU9vanJ0RkF5?=
 =?utf-8?B?WVM0ZzV6R0tKaFBSdXUxY3o2akhSOHFNR3FiT0phVHdLL3ZlemJqMDBSS0dm?=
 =?utf-8?B?QzJzZDRoWTU2cittdlBhZkd2TGp0VUljeTJZYkpialN1ZEY3a3BEbXp0cTJh?=
 =?utf-8?B?b3FNNVI0bTJEbk9ocmNkR0ptUTdKS29QdUJZampmNEg3WlNzaXdKVTNDNXM1?=
 =?utf-8?B?REpxcWs1MHlhcGsvK0NaRTlVeUN2OEhPYjJBbmlVZVpZKzFLeXlBUkZ1MWJF?=
 =?utf-8?Q?hdPtwhBmKVRLhcNhysNEJN9Ws?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2075d211-2e87-4b60-5940-08dbde96eb9d
X-MS-Exchange-CrossTenant-AuthSource: MW2PR12MB2379.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2023 07:06:38.5628
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JO113acW/QJlrNByWBlOotZgW7WrZu9N14F5oJVf9SYVAx6BvlxJXF6rZ3qAwwYzqBnx/V/IAmGaByy25nmblA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9413
X-Spam-Status: No, score=-4.6 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,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 lipwig.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 (lipwig.vger.email [0.0.0.0]); Sun, 05 Nov 2023 23:06:53 -0800 (PST)

Hello Chenyu,

On 11/6/2023 11:22 AM, Chen Yu wrote:
> On 2023-10-27 at 08:57:00 +0530, K Prateek Nayak wrote:
>> Hello Mathieu,
>>
>> On 10/19/2023 9:35 PM, Mathieu Desnoyers wrote:
>>> Hi,
>>>
>>> This series introduces two new scheduler features: UTIL_FITS_CAPACITY
>>> and SELECT_BIAS_PREV. When used together, they achieve a 41% speedup of
>>> a hackbench workload which leaves some idle CPU time on a 192-core AMD
>>> EPYC.
>>>
>>> The main metrics which are significantly improved are:
>>>
>>> - cpu-migrations are reduced by 80%,
>>> - CPU utilization is increased by 17%.
>>>
>>> Feedback is welcome. I am especially interested to learn whether this
>>> series has positive or detrimental effects on performance of other
>>> workloads.
>>
>> I got a chance to test this series on a dual socket 3rd Generation EPYC
>> System (2 x 64C/128T). Following is a quick summary:
>>
>> - stream and ycsb-mongodb don't see any changes.
>>
>> - hackbench and DeathStarBench see a major improvement. Both are high
>>   utilization workloads with CPUs being overloaded most of the time.
>>   DeathStarBench is known to benefit from lower migration count. It was
>>   discussed by Gautham at OSPM '23.
>>
>> - tbench, netperf, and sch bench regresses. The former two when the
>>   system is near fully loaded, and the latter for most cases.
> 
> Does it mean hackbench gets benefits when the system is overloaded, while
> tbench/netperf do not get benefit when the system is underloaded?

Yup! Seems like that from the results. From what I have seen so far,
there seems to be a work conservation aspect to hackbench where if we
reduce the time spent in the kernel (by reducing time to decide on the
target which Mathieu's patch [this one] achieves, there is also a
second order effect from another one of Mathieu's Patches that uses
wakelist but indirectly curbs the SIS_UTIL limits based on Aaron's
observation [1] thus reducing time spent in select_idle_cpu())
hackbench results seem to improve.

[1] https://lore.kernel.org/lkml/20230905072141.GA253439@ziqianlu-dell/

schbench, tbench, and netperf see that wakeups are faster when the
client and server are on same LLC so consolidation as long as there is
one task per run queue for under loaded case is better than just keeping
them on separate LLCs.

> 
>>   All these benchmarks are client-server / messenger-worker oriented and is
>>   known to perform better when client-server / messenger-worker are on
>>   same CCX (LLC domain).
> 
> I thought hackbench should also be of client-server mode, because hackbench has
> socket/pipe mode and exchanges datas between sender/receiver.

Yes but its N:M nature makes it slightly complicated to understand where
the cache benefits disappear and the work conservation benefits become
more prominent.

> 
> This reminds me of your proposal to provide user hint to the scheduler
> to whether do task consolidation vs task spreading, and could this also
> be applied to Mathieu's case? For task or task group with "consolidate"
> flag set, tasks prefer to be woken up on target/previous CPU if the wakee
> fits into that CPU. In this way we could bring benefit and not introduce
> regress.

I think even a simple WF_SYNC check will help tbench and netperf case.
Let me get back to you with some data on different variants of hackbench
wit the latest tip.

> 
> thanks,
> Chenyu

--
Thanks and Regards,
Prateek