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 243E0C02192 for ; Thu, 6 Feb 2025 03:07:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B43F6B0083; Wed, 5 Feb 2025 22:07:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 93DE4280001; Wed, 5 Feb 2025 22:07:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DEB66B0089; Wed, 5 Feb 2025 22:07:32 -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 5F5C36B0083 for ; Wed, 5 Feb 2025 22:07:32 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D99F0120E9A for ; Thu, 6 Feb 2025 03:07:31 +0000 (UTC) X-FDA: 83088034302.23.638BC9F Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf28.hostedemail.com (Postfix) with ESMTP id DDBE1C0006 for ; Thu, 6 Feb 2025 03:07:29 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=mrxlZ9u4; dmarc=none; spf=pass (imf28.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.221.42 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738811250; a=rsa-sha256; cv=none; b=bXoNI8fWaI0l+8ad5qfHBbhtiSerjQq0gkRDwMjNZewp2JSDdyRTZvkpxDOW1pCRTEkANo Po2U1eDybIjp9TSIsPzwHz0DvVJmmv9KWmYcTmdWuOQV7Zr/UDHjzZBWtyXe0eG6AIQSF5 41tfJlH4/58O4/v3ecDWqbA3ukSyQfQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=mrxlZ9u4; dmarc=none; spf=pass (imf28.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.221.42 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738811250; 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:dkim-signature; bh=d0X8Qu1oJSGxAxKqVwaotR6zN8wjOFVNqLjZMWyUans=; b=wovXTbhz1/2P89rF4L+ENZGP7mCkCudz30vKeX4Sf5LgF1wqU2Xq/cpnm/fI6r0yzzMd1r VV+RPFxdbCO/PoSy3koI8719QFEJvaqQMJOA5k+sqCEDnkJKg+p9lsZ8UcBE/k/D1okNj2 MHq+6RmfHS0nZI9rnGjt4ZDbF/0tAgA= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-38db0146119so210911f8f.0 for ; Wed, 05 Feb 2025 19:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1738811248; x=1739416048; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=d0X8Qu1oJSGxAxKqVwaotR6zN8wjOFVNqLjZMWyUans=; b=mrxlZ9u4ado/72B+qEBLv3+OL28ynljU9DF49OEHXCxcJSEeRlbz3H8odgl8NpwTRM wOF6i4lruP8Z99aPE5KlJzz6GZ0I903yLxiGw/GZRpC0h1MW0FB9teUufSM65hx6UZFV AOAJc3pU3402pIEfvaJ8Kd+r0AG6Y7zFURHHs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738811248; x=1739416048; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d0X8Qu1oJSGxAxKqVwaotR6zN8wjOFVNqLjZMWyUans=; b=w00F1qQgFYdreHPPZRAskleBkAO5UD8xTyFku+HvHcItWJMVsXbv7d6Q9PVyCTKPOb AuE4PUYSW4fFP7uM0zT31M/fvxrriuUm307mTpncEAnG/9OPTyJ5lgNfJfo08T4+56QN KTzfS4+h4Lgq0CkSHMObp62VP2yA6BVgFR677o8gT5i94AGjvUqnImklkrDjlt6LZjmI borB5ccfYv98nnn9aF24m8JxoM6gFPyPXo5U3xUfS3DH7LRIjJMEnJnXRrir6u3d4DL6 VDmTNR3fktLTlLdst6aQneaoB80wOjno2fMrzyVvzQdZtDj8+4au2dE2qChXSse9I42f Vqhg== X-Forwarded-Encrypted: i=1; AJvYcCXDfFb5n7W6mc6ZGigZylmmNfKKcZAdQsyMNCHoeDT7q1v71IbxMrK0V51o4bIMMPuIkVYYLeEPkQ==@kvack.org X-Gm-Message-State: AOJu0Ywv0Jjqt3ty7hQt6EPLhUtMo2qy+uv8zCYXhCHZQnrT838pAo2y 26inzZ5J9/3B0YAevuxzkiJoBrFOkJAksJPjS6oFFAo2aQ3OBJebZRt2CJ1wNwMTsz9Hno6vPbp wOBXxFYzNuXTRSy40GXU3tLzC5jeF4loeH04fvw== X-Gm-Gg: ASbGncsdrS4hnJhRo4da6Tfm6Cjhnyc4zcrmC0ChDPvas+98Cfq/jbYpduUkvIEZDhT qTCfyVF/lE/kZN968jkpO9BW2LBzDOT9i1cO1zqkCyxnGYgqdqpN9dXfBlxrV1cHxN7LVkl7euQ == X-Google-Smtp-Source: AGHT+IFhCuN1t2tSucTEB6wYu/3LdGn6xhB9nOnrSGuYM34cTxwvwctQ7cqu4dBDoTsr5WE6bqYMaA9XqkDKEEosVBk= X-Received: by 2002:a05:6000:2a7:b0:38d:b82a:d772 with SMTP id ffacd0b85a97d-38dbb3063f0mr1050674f8f.26.1738811248129; Wed, 05 Feb 2025 19:07:28 -0800 (PST) MIME-Version: 1.0 References: <9DA1FAE6-A008-4785-BDF9-541457E29807@joelfernandes.org> <20250204220418.35949317@gandalf.local.home> <20250205081635.397eacb0@gandalf.local.home> In-Reply-To: <20250205081635.397eacb0@gandalf.local.home> From: Joel Fernandes Date: Wed, 5 Feb 2025 22:07:12 -0500 X-Gm-Features: AWEUYZkwb1UDNJpqESrHKgdguvt7oY_uHNtRCVindKlblx5I3avE0g0lh8l1mXY Message-ID: Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice To: Steven Rostedt Cc: 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 , bigeasy@linutronix.de, daniel.wagner@suse.com, Joseph Salisbury , broonie@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DDBE1C0006 X-Stat-Signature: zpyfd6a1rd1nuwq1krqu6u8z4119b7tt X-HE-Tag: 1738811249-306817 X-HE-Meta: U2FsdGVkX19rYBYDJgn7kRuC0LFodjUVVSFrpIOLNigL8VjziQ8Ykj5uJ/BPbrOwUVrAXF87PCPD8xfto3bhyz4TO0r2frSmPFZXGl67rf1hrLbMViIamCtW5quVeaw5rYD3kAT2hmewODKWbbdgZqiSPOzGCDgw0zdQgGIEf5jE7sPLRqmuCl69lzHD6Ds4c22m6lOC3M6epzJTS4lrFbErZ8cmPN6tDcM7p9Cq56931eodpXSUC0XJV2KoekAQ9APf7Zg3fK2pB4AACidGuMVektUsDuRWz5y0RhHSlq1yowiNx3lueOQ2tDMV9RedeoJlwk1SO49m97H8gU9SKs05gWQDW7cNA+AgtRfmcbYK083yhwSHgMzr1wYQGmjL/oETBi4z5FTc2v24LaWJaAHdrFk7Z9euoIM487zliRdhKitDbO1PNEQQN8LzWUJUlEwopo9Ar4L4ibX+st3joF33tHyLs+VLCbZTawoBXv6LBTkm8N0NqucHA5f2gRuM+CKjNZ4sYpO8h4ArGI0kM+LVBWNtP8QficuZ/AEBb0sTm+FgzMcC9qM+MAVintngzEMDst66wvyDldPot7SgJB5U8cn6q1Dd63NwcMrPCObtJxTvaTHV8qsXCVQ2DcnyEqZ9+W1WrjNnHEJsEn/qsqdukOMRtz/RLI0hVzt45AgQ9k5l0pXb8th1agIO6o9JsqoX7DlwNnCXgNqySNP+Nw3oKXrczFm8SZ/D3QMwwoXhiIJeUtLsvpMfR3ePDd4PLZMQsfTUFwfIpkS7OenQihK8OTyDn96DNjhImvjYSfn4BrlV6tNKWivcbjPefkDiN1yqJ9d41FFSR9VOxdLfSairCIChChDHU1uxiuLsu6uK+9nhMzmBw9Pgj2jxOPh9E4WCMDZpLNWyCl98piCuCPcD7O5MDI9GWQQ/MViR+HU/dB4lHD1Rn4Lf04oFe9WmajmRNX1GUGEy1dfTcO4 ExjrClSj F/oDPDX2m4SdFT/6dGP8e0fBzJITHrK1qRHyOJZ2KsnCfOLPxSnUlORUPI007eRVSogza4M6bHHjrRdf6qHSKcAn1bHjWMuYeo07FzXSiGJ4w/8QAXOmff6909Cii1JH7Y/IRzjBW4gb/2Az2baHNIj+KW3WXWptOvp240DHeWM/n+DaJoxQFd8CskUT4i+DHFRo/9rmT8AUUf9AkIlSZNBgX2pIUn8NIFOzwpJin3k6n6K/u2o+3Zv1s8D9CGrGmp6uKOhr8Gu8K9+ZOruOHZMILSBS3U3cR9PZ5knv2Sz8mon/7cEQ34KK18iYGIPrCT0ft53PRN5wXQ2E= 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, Feb 5, 2025 at 8:16=E2=80=AFAM Steven Rostedt = wrote: [...] > > > > > And you are also OK with allowing any task to make an RT task wait lo= nger? > > > > > > Putting my RT hat back on, I would definitely disable that on any sys= tem > > > that requires RT. > > > > Just so I understand, you are basically saying that you want this > > feature only for FAIR tasks, and allowing RT tasks to extend time > > slice might actually hurt the latency of (other) RT tasks on the > > system right? This assumes PREEMPT_RT because the latency is 50us > > right? > > RT tasks don't have a time slice. They are affected by events. An externa= l > interrupt coming in, or a timer going off that states something is > happening. Perhaps we could use this for SCHED_RR or maybe even > SCHED_DEADLINE, as those do have time slices. > > But if it does get used, it should only be used when the task being > scheduled is the same SCHED_RR priority, or if SCHED_DEADLINE will not fa= il > its guarantees. > Right, it would apply still to RR/DL though... > > In any case, if you want this to only work on FAIR tasks and not RT > > tasks, why is that only possible to do with rseq() + LAZY preemption > > and not Prakash's new API + all preemption modes? > > > > Also you can just ignore RT tasks (not that I'm saying that's a good > > idea but..) in taskshrd_delay_resched() in that patch if you ever > > wanted to do that. > > > > I just feel the RT latency thing is a non-issue AFAICS. > > Have you worked on any RT projects before? Heh.. I think maybe you misunderstood my statement, I was mentioning that I felt (similar to Peter I think) that NOT adopting this feature generically for all tasks due to a concern of 50us latency maybe does not make sense since poorly designed app / random hardware already have this issue. I think the main concern discussed in this thread is (and please CMIIW): 1. Locking down this feature to only SCHED_OTHER versus making it generic (maybe sched_ext could also use it?). 2. Tying it to specific preemption methods which may change user mode behavior/expectation (because LAZY is tied to preemption method). 3. Overloading the purpose of LAZY: My understanding is, the purpose of LAZY is to let the scheduler decide if it wants to preempt based on preemption mode. It is not based on any hint, just on the preemption mode. I guess you are overloading LAZY by making LAZY flag also extend userspace timeslice (versus say making the time-slice extension hint its own thing...). Yes, I have worked on RT projects before -- you would know better than anyone. :-D. But admittedly, I haven't got to work much with PREEMPT_RT systems. - Joel