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 88978C0219D for ; Tue, 11 Feb 2025 08:21:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CE136B0089; Tue, 11 Feb 2025 03:21:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 77DFA6B008A; Tue, 11 Feb 2025 03:21:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66C156B008C; Tue, 11 Feb 2025 03:21:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4A62B6B0089 for ; Tue, 11 Feb 2025 03:21:45 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EC5C2C1353 for ; Tue, 11 Feb 2025 08:21:44 +0000 (UTC) X-FDA: 83106970128.22.218D3CA Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf21.hostedemail.com (Postfix) with ESMTP id 2A9631C000C for ; Tue, 11 Feb 2025 08:21:42 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hmM2KBL7; dkim=pass header.d=linutronix.de header.s=2020e header.b=iP3Ax1Kp; spf=pass (imf21.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=1739262103; 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=9BlClQg/igJMGUDxsPh2k6TNuhBuRDg74jGMgRLHdWM=; b=WmAp2Ep02//kd/8Dp6UrSmRPnyoRY/fUdWWf4VH/6z9kHgd60dZVaxzERyj/9JFKJaW9Yd fCj/4Z02Yu/zZcgTY6q5s8mQROYqa53SosIv2QjD9kfQa1Ek21wmmhPvC6MmsXbMpBt67o eIywmKHVC2pE/D06RN46zLubd/7NfeM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739262103; a=rsa-sha256; cv=none; b=Nyw3bSc3fNqN+csFj1Bs1PhdEtC0eipJ5MjrRUhkeDILGK/fiQ5JVw6RorEMJOGPGXtz4P sr/O88PaDrZljE7cxpcNQypmOdiTPICzBmD0JVVSYBzsZb+xZ0t8VLbX7oL6jo0mSqEcx3 eszLL8KCv0ePvWtMfZFwmR90wrv5Ih0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hmM2KBL7; dkim=pass header.d=linutronix.de header.s=2020e header.b=iP3Ax1Kp; spf=pass (imf21.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 Date: Tue, 11 Feb 2025 09:21:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1739262100; 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=9BlClQg/igJMGUDxsPh2k6TNuhBuRDg74jGMgRLHdWM=; b=hmM2KBL7vW7mDZ2m2kbRTvbCD1THEqo2LjN8tx/vGwvctzhHHXlVAEKUGpfESAL9YPhBuv y/HN+6gdC4qlUDrFdwiEBbsBrDEnipn3X82MeQUJcSiYJSsiWU6g/Olxzg5PyhNtdzy5dw r/rM9M3gk0pFfH0vlgy2kdbsgCOYUeqI8YtU55mv8gsAm75duubgX1U0D/2qRthLx+x4UL DfPlPP3TlAi4/1nvJV5qZUKm5vifF1I91EMjwFWYLwjUeiLfyDZankUhBfu4ktYQkgEaKf ubojmPUwwhuHGpigHEGo0tXB0t9qW8QCmwHJpVsmeDx6egZpC9p2C1qOALhEkw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1739262100; 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=9BlClQg/igJMGUDxsPh2k6TNuhBuRDg74jGMgRLHdWM=; b=iP3Ax1Kp6OqZ6pKpSWuFyA+erFCUcCmN36r5C/3Jpzbml2Ws6g3A+h3Boal+r6tX6LYeNk SR/VoVg2YhdwQaCQ== 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: <20250211082138.iqvedSfG@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250210144321.1f5974a6@gandalf.local.home> X-Rspam-User: X-Rspamd-Queue-Id: 2A9631C000C X-Rspamd-Server: rspam07 X-Stat-Signature: u644g7tjfw3z9rq8cem39hqm5g4h6uws X-HE-Tag: 1739262102-926826 X-HE-Meta: U2FsdGVkX19A/VBFHSNVK/04bzQaYEnMRJ7/qEstbBrEInvruShr0y9/nRsn0o4rCVnB20iD9H1V2w7gZkCv6lsLU6kY02jlKtfftyIXOCOwtfd3vM/cc7II7GlRM6sUqXnGaAzbH0mG6VJ5r5wHaBvOLfHTpEWk0QemhRdMr2w2oHZWGnN0wBgZ8SZvx9r7Cu8gc/DSvOIKr5gqLjYntuc3HJwFTZ6TaVB+7dRMiUkOz4M6WvWUOt4HQSjtVnTjjTicx6YJYpCzMXp6xeAOU1d/5JwNZdNuyu4eUj88Tv/mqfKjX/Bw5ixEk7JwLQNLN+50tLBoaoI1Wx1j8fFGO1vHLDbZic30ccs3v/e7lp/lm2sCywmD5d4ZQrfwe7o5Dncm9Wf1xfTijKqCv7+Sp/KMx0LjbsFug4ItEs7dZsgOyOFlLCIYdYsMr0vURsEXkcTFdgepCquFUrh82sbT6+Nf/A7JrIOdWV2+GX1m4yGLlS25Fl/vGEJZ4FMogmW/P0wFQOe0LBLxGojoy12GAN6M1LrVoS+JQflZ5fbm4Z9EFVZscjE2WoaO5DNYSv+F2Xeyc07EsAD3OZxtiRLgc8k6D/MFQW9rhgE9d9HJIVPyhneOIvW7C2ViJ5k/J0vL36L/JTv1xkdpGwJ6vNmq40n2NhtGqNWKQnZxYs8Ek1sUeVxUoBC+ahhBL7LmKEBXRNT7wcYeVEi2DBHMyUhVv0aUUp+6Q1DvEijo6lV744Q+Ut8vDyrvfUWggrGENj2O84dDRxCSsT1ntB4YnKE2ZHuCbzMHBeeiAvpRInPsDDljmh+9/GEqdH0AdDVLAuCqaM9tdINn/hd7gHXdYkhdXAZ8rhItolrGbeHBkMsNZP6cUA07YzInC/LVoh7qdIp3x0mb0ro1EmZZ5wuZx0ICfcygRGCb+73ruwIcFOHcQCp4rfs2dNycvzJ9lMdk5pvs7aHGfzwqjwhxT2N8Frd 110X3PIP ruo+6/TNY9idHL6Uxo206x17jhnjjdj9T+kwPah3hJrqpWYfqZNur6jnAjr4awhkzM65BYZFSxh0WwxbsTX+0iIzF9w2mR0hYkoAWvpwHh4MHuEm4zE+DztsIWhjMUplrXUdck8ezrIaq9M8evXPxTQnqVfAAJWAQ7gEv55hk7aQMx6e5F1tAs1D+E+rceBO60sUmxOD7+LFtg6oWLyHZDcbdjCXT/fIolw0eBC8sDtvibSQI1FN2uiq6YdN1r9/68in6fOIkGlJz39w= 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-10 14:43:21 [-0500], Steven Rostedt wrote: > On Thu, 6 Feb 2025 14:44:08 +0100 > Sebastian Andrzej Siewior wrote: > > > I did add a scheduling point in rt_spin_unlock() if LAZY was set and > > based on few tests it was something between noise and worse. It seems > > that "run to completion" is better than interrupt the kernel in the > > middle whatever it is doing. "Don't preempt the lock owner" is already > > handled by LAZY with the scheduling point on return to userland. > > Does that mean that PREEMPT_RT requires a non preempt method for > SCHED_OTHER for SCHED_OTHER to not hit the issues that we were originally > hitting? That is, with being able to preempt spin_locks in PREEMPT_RT, > running a system with PREEMPT_RT in full preemption mode will still suffer > performance issues against a non PREEMPT_RT running in full preemption mode? So with LAZY_PREEMPT (not that one that was merged upstream, its predecessor) we had a counter similar to the preemption counter. On each rt_spin_lock() the counter was incremented, on each rt_spin_unlock() the counter was decremented. Once the counter hit zero and the lazy preempt flag was set (which was only set on schedule requests by SCHED_OTHER tasks), we scheduled. This improved the performance as we didn't schedule() while holding a spinlock_t and then bump into the same lock in the next task. 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. > -- Steve Sebastian