From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0CDD2C02198 for ; Wed, 12 Feb 2025 12:11:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D1F8280001; Wed, 12 Feb 2025 07:11:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A8ED6B0095; Wed, 12 Feb 2025 07:11:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 470A6280001; Wed, 12 Feb 2025 07:11:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2A0CC6B0093 for ; Wed, 12 Feb 2025 07:11:25 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AD024A192E for ; Wed, 12 Feb 2025 12:11:24 +0000 (UTC) X-FDA: 83111177688.15.9F88934 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf19.hostedemail.com (Postfix) with ESMTP id BD3EA1A000F for ; Wed, 12 Feb 2025 12:11:22 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=uT5v+mE7; dkim=pass header.d=linutronix.de header.s=2020e header.b=HM5DkrZ9; spf=pass (imf19.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739362283; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7TNBT0J/OEy8YxJkvBLL8wlR8TSxY9KLsjAwzg3RD5Y=; b=UVwIAm3TvSQ0ONfp5ukPTh2aQmV+aPq3GDmx4222zq05LpcL2IYQkjEW8e/3RKJs2PDtgb yr30Nd9uRXs6E8Tfj+wUgBaQC90MAMUAYbljoYD6fO5Mv4Dl5S0DMnkixIWgbTwZ0ldImm Lim9k4HmZWg7U18zL64I65QaLt9lAVU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=uT5v+mE7; dkim=pass header.d=linutronix.de header.s=2020e header.b=HM5DkrZ9; spf=pass (imf19.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739362283; a=rsa-sha256; cv=none; b=y2+z5LXNyX+ZsAs+rmS7J4v3XPuM4OiS3vYc8EXcKm0+/ph8KxwgzIgz7VmUFef87MR17V KDqJQztRks87LQHi/76gmzXiFQxjmDlnsJQz/eYDuYbGpGZDDgKcW1PYwUKvSLoJN0DehF V/bOfsVR0WrBQ6+Yy2gk1UQFM6XJk7c= Date: Wed, 12 Feb 2025 13:11:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1739362278; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7TNBT0J/OEy8YxJkvBLL8wlR8TSxY9KLsjAwzg3RD5Y=; b=uT5v+mE7N7yeiBRcXKtyRYO25ZC9j8Al4cOBRuno5OOctcw+aDUpqUPq92BdBifezgbN4F 9u+a5LXCadMGf6UplzQwmBaCwNvZ5Z2wdP5hJCIkSFhkv0JGifwTvkclQTGEn72aqmgOPP GysGRoHIRsVAufNid/6utAkCZPUlQcsr1BljCaF65CDGDOhTIW0i1iKUw6n2mJ9lVBw61J DOnEtcQmoUCJd1TfszpTIgI/Re+kop87GPKG+ky1DKH14ZPhTwceihO1vQfpZa8pwxb+kV q/CWy/BLAU5VYT9/uUUfIrB/vSHzRklLEfvz0dUbuGM4vK2Cotxm256RPucmNA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1739362278; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7TNBT0J/OEy8YxJkvBLL8wlR8TSxY9KLsjAwzg3RD5Y=; b=HM5DkrZ9tyvbTSgICy7zFN4UfAQH4az1YxHKFMneOnIGHrh2cP4SqEkoDBPucxmk1g+KTF o8BHvK+H7Orm/QAg== From: Sebastian Andrzej Siewior To: Steven Rostedt Cc: Joel Fernandes , Prakash Sangappa , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Thomas Gleixner , Ankur Arora , Linus Torvalds , linux-mm@kvack.org, x86@kernel.org, Andrew Morton , luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, Boris Ostrovsky , Konrad Wilk , jgross@suse.com, Andrew.Cooper3@citrix.com, Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Mathieu Desnoyers , Clark Williams , daniel.wagner@suse.com, Joseph Salisbury , broonie@gmail.com Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250212121113.3nJ-kf-6@linutronix.de> References: <9DA1FAE6-A008-4785-BDF9-541457E29807@joelfernandes.org> <20250204220418.35949317@gandalf.local.home> <20250205081635.397eacb0@gandalf.local.home> <20250206083039.0916ad24@gandalf.local.home> <20250206134408.lD_POjuG@linutronix.de> <20250210144321.1f5974a6@gandalf.local.home> <20250211082138.iqvedSfG@linutronix.de> <20250211102801.5b32d610@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250211102801.5b32d610@gandalf.local.home> X-Rspamd-Queue-Id: BD3EA1A000F X-Stat-Signature: s3y8u8588i4uni8eqp4zog1dm559dctm X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739362282-262912 X-HE-Meta: U2FsdGVkX18HnGFpmL7KxAMLVu0+1FFogXGVSBa+5DLm7htzHtHdkbK4v9+qSF6eb+fyDlKivGQ0Ln3JcHB1zLbF46bSNgxjDZjrV0p3oo6D+z6WYlP2taIxS926w/7Y+L4X23lP+jlG03O7bLnkh9RUPXNZiF69/MyejPiBZChmdTPntcXEzvf0eMM43/sA0n8M5tHZ8IEtjfnvtLoohyN50rXs9dA/cVfrJNmSLdevKFl0lhCctbRT4rGnQvuoPUTy3jb2AH5hJGxW5DbDekTq6Q7AmS4jw0jd8MAmbvmCbV+KhaY6O/r92+Qc3Zxd8Wen+lKO63vqnEVd25b2TFiJMRBy39FasLLk+CnT+VP2ctfNSyZrDPo0hoVpBIlJFnMp06AcChfwbHa8FiuduG2weMfwP5F/g9wwi1q1p2A2YiOlEYwEJQg74VT18V0oG0ke/dt/7yXgNlX61GnUdqCH//pEhTMxdxWUWDCeUQp81dBtCp8i7XXX5fVYLcqcniod0AxQpJqY49ZZbDkkI9++4CWDbVyYXhfg4JG8WyiQ0WAR1ytScGzXBB+RPERhmTQuqJ9UmTiAcZBgFW/HU5+4+5hOwhGRq36edPXO3KP8zcj00YtovxPuVMnC2NNxp++6Tyn6VFDqXjVS54KCDvnu8RJmWMsq6JzbxZSfytuTWvfqytsQtHPIZlHuo6NxDDlRMZS8W6ed3Pxwql9sh/5re8RydreoXmco1GaqoU5caj0/qDV5lXfebO8jXK0A5PZ6a/fgz6LmlleK2pH5qS1btmLY6X5642n6FxyQOOnZyRqtjazaScNZKHD7IMxJuhihB9ax4xLHzMugHpiLYSExfFPrry1klfSK+HuVieaJR4Sn4VeG99tWK2k6B4TcVrZGHFYywBpeiPdJ23hZoO27gBtEwMm059aaJa4tD+G7Tx9y6VxGaymVLiNELvTU9hfduuWqZahk0/4066Y lJv5O21u G31RcHxHR4W4Ex+yLzpmSiq0jSCkYf9qKYFFNvk2ENtoFd3LgY4LHnCP1/SqCIc8id6PMTJvjDW4LZ6ymcP6tcoflDvDI9cdBd/ctCzqo5poNk9ZXsGlBFuVg6NC2vAQutRQLPC3l369c8xMIk2wlYZiKe56D5+4oAsQVVDoiiBIlbZdtM3EESFjCk7/hJ0CxsQF3oPKiCSXWMGW1TViriH8guW74zv/2lq+28NUWWG6zvSJsXVA72kW+EW3nY1G8/I6y23EmUO+zPbJzOLcU91LAxW1TJY96JCDg X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2025-02-11 10:28:01 [-0500], Steven Rostedt wrote: > On Tue, 11 Feb 2025 09:21:38 +0100 > Sebastian Andrzej Siewior wrote: > > > We don't follow this behaviour exactly today. > > > > Adding this behaviour back vs the behaviour we have now, doesn't seem to > > improve anything at visible levels. We don't have a counter but we can > > look at the RCU nesting counter which should be zero once locks have > > been dropped. So this can be used for testing. > > > > But as I said: using "run to completion" and preempt on the return > > userland rather than once the lazy flag is seen and all locks have been > > released appears to be better. > > > > It is (now) possible that you run for a long time and get preempted > > while holding a spinlock_t. It is however more likely that you release > > all locks and get preempted while returning to userland. > > IIUC, today, LAZY causes all SCHED_OTHER tasks to act more like > PREEMPT_NONE. Is that correct? Well. First sched-tick will set the LAZY bit, the second sched-tick forces a resched. On PREEMPT_NONE the sched-tick would be set NEED_RESCHED while nothing will force a resched until the task decides to do schedule() on its own. So it is slightly different for kernel threads. Unless we talk about userland, here we would have a resched on the return to userland after the sched-tick LAZY or NONE does not matter. > Now that the PREEMPT_RT is not one of the preemption selections, when you > select PREEMPT_RT, you can pick between CONFIG_PREEMPT and > CONFIG_PREEMPT_LAZY. Where CONFIG_PREEMPT will preempt the kernel at the > scheduler tick if preemption is enabled and CONFIG_PREEMPT_LAZY will > not preempt the kernel on a scheduler tick and wait for exit to user space. This is not specific to RT but FULL vs LAZY. But yes. However the second sched-tick will force preemption point even without the exit-to-userland. > Sebastian, > > It appears you only tested the CONFIG_PREEMPT_LAZY selection. Have you > tested the difference of how CONFIG_PREEMPT behaves between PREEMPT_RT and > no PREEMPT_RT? I think that will show a difference like we had in the past. Not that I remember testing PREEMPT vs PREEMPT_RT. I remember people complained about high networking load on RT which become visible due to threaded interrupts (as in top) while for non-RT it was more or less hidden and not clearly visible due to selected accounting. The network performance was mostly the same as far as I remember (that is gbit). > I can see people picking both PREEMPT_RT and CONFIG_PREEMPT (Full), but > then wondering why their non RT tasks are suffering from a performance > penalty from that. We might want to opt in for lazy by default on RT. That was the case in the RT queue until it was replaced with PREEMPT_AUTO. But then why not use LAZY in favour of PREEMPT. Mike had numbers https://lore.kernel.org/all/9df22ebbc2e6d426099bf380477a0ed885068896.camel@gmx.de/ where LAZY had mostly the voluntary performance with less context switches than preempt. Which means also without the need for cond_resched() and friends. > -- Steve Sebastian