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 529B8C02192 for ; Wed, 5 Feb 2025 21:19:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC22B6B0083; Wed, 5 Feb 2025 16:19:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B71E0280006; Wed, 5 Feb 2025 16:19:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A393D6B0088; Wed, 5 Feb 2025 16:19:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 84EFA6B0083 for ; Wed, 5 Feb 2025 16:19:13 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B0FF780B9C for ; Wed, 5 Feb 2025 21:19:12 +0000 (UTC) X-FDA: 83087156544.14.A50AE9A Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf24.hostedemail.com (Postfix) with ESMTP id 1711D180009 for ; Wed, 5 Feb 2025 21:19:10 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738790351; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QK9MWodXdSPFI4GNykHQsbIOJo3xffOAEYMmMsco4l4=; b=i8mP9ugk+KBC6UfsAbN1yZzwWubHiiQaDDHMhvKQ+3/K/LbltND1uvplp3Sp9GGk59RyhC +oih7Hiqvi3nyiiK9SC6XG5leCoRSXPic/pJcpc5daMV5ikjapGm4RtTFisyLbPAnyvxq1 MEkLIKAVS7Q+wRayB1nLjQP7HxBKdxI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738790351; a=rsa-sha256; cv=none; b=1Rv5ArFczikKtf2zveuGsFE7rGDTlD/99PbWcLLHTOuav8JP/EOXbY2a95csAzVw1hEN4P szJJxISq1r3GLmhNFePuqlt1qtzqiWf99fkypGZOe3zEqJWmuVtXxWgqh4CoGphd2+Br3T QAksHW1VA3i3kyJXBHFG6EBj38/LGrE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EC51DA43AE6; Wed, 5 Feb 2025 21:17:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7DA0C4CED1; Wed, 5 Feb 2025 21:19:05 +0000 (UTC) Date: Wed, 5 Feb 2025 16:19:45 -0500 From: Steven Rostedt To: Prakash Sangappa Cc: Joel Fernandes , 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 , "bigeasy@linutronix.de" , "daniel.wagner@suse.com" , Joseph Salisbury , "broonie@gmail.com" Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250205161945.44daf018@gandalf.local.home> In-Reply-To: <1A67C4F1-F07E-477C-9781-071546AE3A8B@oracle.com> References: <9DA1FAE6-A008-4785-BDF9-541457E29807@joelfernandes.org> <20250204220418.35949317@gandalf.local.home> <20250205081635.397eacb0@gandalf.local.home> <1A67C4F1-F07E-477C-9781-071546AE3A8B@oracle.com> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: wr9aknf4zsi9ahwhxb84spyeuqoag7fj X-Rspam-User: X-Rspamd-Queue-Id: 1711D180009 X-Rspamd-Server: rspam03 X-HE-Tag: 1738790350-368552 X-HE-Meta: U2FsdGVkX1+4ZSTI6kybNa1ZetbYjea/BCwVrmO40qqZtKCadWFfTfOXgt+gB35i97O9qm/6FCVJ5K4+CCOzwhED3rI1TPt8JK+WNZoXm1TnshY928TfeB/Q4Vz15UxO0DrzbUQeENB6ZKA/h0X3fhGeBcRKNEtxPw1R4fmkIRbZh4Ubbk40QX1OXf+Ov9pcf36ILWu0B0PktOv70C5GId3dLreM5E0rIYbXTcCcQVbY6Ni8JvArthpd+OpU4JjdfRBPQfhtC3GpAzJpKfHW3BWsgkbSi4/TCFu3EqPoNyOEalVfndXyV6iGj+kAx73vc0hTWmrFDPy7H8qbiphcarCGvOboxRdvgJWp2+RHooauvvOtr36O6GH0gtHCYg4qEOpLHhMxE9dMndjxpFSvEAOcHH9M5F9UZQ6hTzX156qTkT8zBPyS6ssP69TEw0QPx9R9ghNCSQ394L+t9NLyXipyYh4tLoo6Ssq0Ln7/3dqPFyo3EHEwde9e+gyA5bfTqH2I9W7gQUf6TlNQYnsjlNepq97cUxaqGQdmhg1GnhI9qb8+6alWUiNlIAS+oZxqlx8Dhdxvu37QPlEUNpOEkRIW7O1rNgawgCznXH4os/liNDZiSHgoNSPY5bBCpdE6N5u4v9AyLgP5/Z+2tnhK7KsRStaw5rxhEKCKvOvNg1Q1eHLrpuqKCfM3H3zM0K4QiC8xKzkAgoW1mx0oSo6koOOaRh+wgNyIwxLiae9IjyzgJdf8hz7pu+3c1K6RfuUZOpRbnTIHZjsvlQi6dGNTSZRY4ej4+E5eIeeUdvmYu0rpEP8ubqHq2q9jc1qqRApPowuS5GGZxGxOR5J+z1Yxe6b+XUQuxt2+EjAvpsNMrTSEdx35JKnio5JoBeBpJjjWCamYsJ05kp/rpg04Tcg7HXwTaS2HN135y09L8I3NM+8qLzVKwIzPrbw1H7pOsetWrMeqlAkR1Km51HAbvOs 6Ht+5wgF bZcmIdLzsPJl02GS8JU4X7J4JbjODqFtpO0xy7JLyMKmTjhKGTWgXrymRpvWQFN463JncU4f9GN0X9Fp0LEsNmVbZjJ7nIiw23Snfe4X8jT1tA+/gOh9wVMeAHbgdZFgYG+FZi7834Vr0teAhW1qLg6U+F1RMeRNoOwetXZSU9UCv4GK8EVDjEO/oJL0KMR29g8e5sxc+7tHz1vA0fxJvXLzWq0ZOept7EN64NI4lfuUPkN/wl5VIh1yNL38h75lcYdZtu2m1dOFrg0QPbRx76sJqzqqmSAMpnSMsD6TZ40zLGis+pvcTVe/GDNTuUCN8KaaVNM0HMRAYIJcmS0p9k7zslwBwpeCgab2bAKj0o+L4A//y/s2uPojM7X1aEt4IG57q 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 Wed, 5 Feb 2025 21:08:47 +0000 Prakash Sangappa wrote: > The new syscall/API proposed was to provide per thread shared mapped > area(shared structure) that are allocated from memory pages that are pinned. > So the kernel could access it without the need for a copyin/copyout. > > The idea is that it would be helpful in places where we cannot take a page > fault in the kernel codepath. What places do we need to decided this in a critical path? If we follow my proposal, where we set NEED_RESCHED_LAZY on sched_tick when it interrupts user space, then it should all work out. I agree with Peter about not caring about system calls. If you can do a system call in a critical path, then just use futexes. The only reason I support system calls is for debugging. That's because I write into the trace_marker from user space to see if things are working, and that requires a system call. But once things are working, I'll make it not work for system calls too. -- Steve