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 D5A92C02192 for ; Tue, 4 Feb 2025 03:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE89B6B007B; Mon, 3 Feb 2025 22:28:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D98FA6B0083; Mon, 3 Feb 2025 22:28:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C609B6B0085; Mon, 3 Feb 2025 22:28:56 -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 A7DEC6B007B for ; Mon, 3 Feb 2025 22:28:56 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 129111C710C for ; Tue, 4 Feb 2025 03:28:56 +0000 (UTC) X-FDA: 83080830672.24.9F4F7A8 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf24.hostedemail.com (Postfix) with ESMTP id 3D6C4180005 for ; Tue, 4 Feb 2025 03:28:54 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IkSTVvnQ; spf=pass (imf24.hostedemail.com: domain of suleiman@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=suleiman@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738639734; 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=ypnXRpVd7BRYU9e6tSX+xvv2lBSXpI+Wfpw7I5WJkzk=; b=1kSkl18Go5MlYCoTNRdeJYCphoLSJ0np/yWsNJhe0xUKEYrvg0IQe6pni5lqOi6voxE7lf 2a1YYAim9SDT/ob9WuJi7K0XdCPFZmjWQY5IJE6HrayECptEZDFoSwxB8SxL+0vWkkC0aj vADREt75p6xlsNcgJ3lpgcJs2ygLnPI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IkSTVvnQ; spf=pass (imf24.hostedemail.com: domain of suleiman@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=suleiman@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738639734; a=rsa-sha256; cv=none; b=tobXYty6fZ5UUr/Q0bZ/lZa2jqYnMidhI6wIkcHu/aDpMWeqYCBagmgMNu88EoUG96tATn oPCUqhFLyaOWpH82QTc5AIxMCBM0ltMh6XqZfdSdPdQoOqAx1vxU2mtHVwsXilioRnyWjD 9G/gTaFul2112idLwVRv8oRA3EofY8w= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-467a3c85e11so32085301cf.2 for ; Mon, 03 Feb 2025 19:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738639733; x=1739244533; 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=ypnXRpVd7BRYU9e6tSX+xvv2lBSXpI+Wfpw7I5WJkzk=; b=IkSTVvnQvxqAyMKkhRGYA2GFfc6UTE/vumRSpiJndEsPjNPZYjdaeJeQbPmZu1QB2l WzrU2Fs89l95raUMg7YUpWwrxucfcqdoZ92TlyFXV4N4Ws09RRYGJ2YSbvVRUcL5XMRh vn6rU60MGG085YfC5I6WUdiwNji8ICEVbYxjJ6nsjLbO0WTodeQmXRaGgw/32EMebaY5 UjIAaxudKgUYNi9cJMseR7GLxgbnVPeHXm4NWhwl12AaC9qBvwiRH5c7S4RTwDWJoGJC i2eI0SbID8EkmSgqiyw/afOuVntt5BdSIxuG49A4/Bf+h3Ec5DeVJzKZZrrGVNpoOROA Eecw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738639733; x=1739244533; 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=ypnXRpVd7BRYU9e6tSX+xvv2lBSXpI+Wfpw7I5WJkzk=; b=jdUmhMFlfEFwtEtLwYxwzZr0LqraXD3miZMSVUkseo1fZXyzqpRr2IFiGY16I+anAy 53jm0Lp3UvxuCFKLYaK3hnpvmyQliw7yU+MjUQB3C2Gm3Glo+O9hncw/NJoNedHZNA0q mrsHFciMrr1o1EPxNTMhOdx6DnUSPazZYpEaQqqEhuOLBgNY0xx3+7Qa0w84rN2u9d1o 7KDbcWR7OZoIXkwUN8Fr7hSV5y6fCz8zdQ4bffKXSnZ1BaYFS1Wiq1nwVJfDWm7MSBb2 FIV2SE3MQFF6QI4pVGB3bzRUAMZrZeZs7YTfav4HB66ePsLCA3xQsj1gY7bcXvFlRYE5 eOFg== X-Forwarded-Encrypted: i=1; AJvYcCVQOL3Ah0QH7Pg3aXFZ3EuzV3lvrA2oTiHMcv6iCzFXTQV4S2MBXTfWSB5uPhGjOsw2Mw7fGHVhHQ==@kvack.org X-Gm-Message-State: AOJu0YwJ7Jfu+fvU7ARcp8ZKRy1oRXy1BwfG4fOlJ6kVD9gDdBkc6nZt BlqWQwvdgWTMErRDWyM54wDVj8yl4k/k5i+dRAkgAgOAjXtUzVoWBaIpsV2m1JfEiwX9q3M1Qjp gDJMzCywzIh+BvxAyqJA74jQg1AGYz066kTtm X-Gm-Gg: ASbGncu4B9yxeHqVltDf7BlhsvlfeE9gHvDtuhkXpLBWfKD/rIpWJZPIcHZat6uz9rp izH+l5JJ3XkS9oF/K6jeejTxhQh+5w8cKPh9mKi+WYT37hWtVmLVoHkRFpMezaylgnU8F+IweCS kdwqzbRoKV96vTE260OUeRuX0U/Q== X-Google-Smtp-Source: AGHT+IG5bOEDDHBdfJysE32rv2Imzn60PeJoxF/B9tX2984Ezu+5ZzfbWrfZIq59LG6nkA3gIiWC1N23lnlu/1Qr4wg= X-Received: by 2002:ac8:5993:0:b0:466:9738:22de with SMTP id d75a77b69052e-46fd0b68779mr367277781cf.41.1738639733200; Mon, 03 Feb 2025 19:28:53 -0800 (PST) MIME-Version: 1.0 References: <20250131225837.972218232@goodmis.org> <20250131225942.365475324@goodmis.org> <20250201115906.GB8256@noisy.programming.kicks-ass.net> <20250201181129.GA34937@noisy.programming.kicks-ass.net> <20250201180617.491ce087@batman.local.home> <20250203084306.GC505@noisy.programming.kicks-ass.net> <20250203114537.6a30c7c0@gandalf.local.home> In-Reply-To: <20250203114537.6a30c7c0@gandalf.local.home> From: Suleiman Souhlal Date: Tue, 4 Feb 2025 12:28:41 +0900 X-Gm-Features: AWEUYZmgt56g4D3b3bmbMMZ61mu-kUiNaRXzg0GoHJpisOtcyPReyq-Z10vSKxg Message-ID: Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice To: Steven Rostedt Cc: 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, akpm@linux-foundation.org, 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@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Vineeth Pillai , Ingo Molnar , Mathieu Desnoyers , Clark Williams , bigeasy@linutronix.de, daniel.wagner@suse.com, joseph.salisbury@oracle.com, broonie@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3D6C4180005 X-Stat-Signature: pwt1geszwy6mf89wr46gw9z6kku16f81 X-Rspam-User: X-HE-Tag: 1738639734-118546 X-HE-Meta: U2FsdGVkX1+AkNq6YHuE8x9MJ9cT20yIoMgh9o2Ej6B0cDNjDK/iKAi4MQkYROLFuSJ+1zW/0Ctv+40OjBQNi5vm58uMbauQNi22tqB6jYiAxLOuH5ETNatDeSNdFgnXdXiA6ObzCO33Nzxvq33yHSw9UldN2PdZw0OmpJpNpXumaASIOLTTaw2XGsOMNpALaICPpfDTRH5VZf9p+1p6fm0wGUZ8u9VegDdj09nI9oDAfG76x6/hnBcgHSB1Qcxm0lOux6yfEoCamRYGFM9ABXbU4V5ESMzhlW4U7qCWJyjs2+dIA4ynpJgiaUG9kD6zXFbya1f3zBSqp0X/RF1xyOfgmZE9/Mj11SSn0oGSweopC3IBMnQ5wyJ1KERW4+oQJUTap0Uu+u3l3esDKmmBrpV7HzQ7LWOdu/giL1XWI7ZqcS3OkEYE219gbixA/u568H8oHgoeZyIkb32iV2CNPGpB9CGiEBUqzJy/s2ZD1XQ4/FGuWXjrYnwExLAhEtrljrhRaJmNR4QLH6PcQLnqgauV1DFonIDyxABxRhtil+2OuF2bUuIWqmN/Lpk9y3A5IEn785EEG8jD98YoRq8RJm/qDEf/p6o7Q3WHPc4Y+Fy+WE9z6qLyILs7HuJOFS/fnuzAnJYNBZqE5+WdVrLHJzmhReonAFKwftdndxaPTubxeGlZD7BLwUnQZUO2ZB1A5UMDanxeyLVYiZ9+EQP9208DGRnCe5fHE+1fT7gLeCJRnOHR5pFKuaBkOhumotQyC23+Ymz+eus1L/Ip5QlDMg9IYjOhckXy4iojKzA26LeckMy8gNINNBF3gWyRvmzQHlhmWK3hXFV0DKpfzMJeOE53Uq5xH1UZWxIcNaZQEIMGu+4L1T7OEXTO36O7B/E/Capo0bkvqzQeTpSq9ifLVuY8W6qnfsJWZKn/PqLl0/pic9FpSJbrGYD34UFOabjKA5JA0wAYRzEegk4g6+G zKN/+Fh+ H/KyrZ82cHqLEWJca6p2tMY7Ci08l83x3mrxgRDAQlu7uu4GdeydPGOvo6QPvfEWHrDMWa1Iy7on9vyKjGKp8pWGk6aWOhrPQSaznffniecIi0rewSypVFb6zcrgROHRyaGUm+qEbOs0XZf6bFlXTfJXw761dYHVjlQI3GxtIvF35hF5wt0DWf7tt495qpMtmz0mxRnDZknthQxlakLa8aUNfwOaObOi1Of2sCAIbLp3FY8qSd+ryaeZo62jPWy+PROKonzHQPuQBHkZzp/oty2N6JE3c69kqAInnpPMGva86Cu+UpslaDo80tBJPukZcfP7Z61NeEbjpx8mT7hIbzGTRhBOFM0N0Db44xRsJhQw2umUO4I0ncynlrJNhTv4lWu+9LkjHpGdNjS2r70+LdOf/HdeulP8ek3HNVZCyEuLzgA+RXUNUmBzoYu9Kk4gIdMTnjfebJ7euVqzSa6ClIL2RiK6ovkHtyump+HsVibR5F8dMlDvUUhhoYQ== 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 Tue, Feb 4, 2025 at 1:45=E2=80=AFAM Steven Rostedt = wrote: > > On Mon, 3 Feb 2025 09:43:06 +0100 > Peter Zijlstra wrote: > > > Lazy is not the default, nor even the recommended preemption method at > > this time. > > That's OK. If it is considered to be the default in the future, this can > wait. > > > > > Lazy will not ever be the only preemption method, full isn't going > > anywhere. > > That's fine too, as full preemption has the same issue of preempting > kernel mutexes. Full preemption is for something that likely doesn't want > this feature anyway. > > > > > Lazy only applies to fair (and whatever bpf things end up using > > resched_curr_lazy()). > > Is that a problem? User spin locks for RT tasks are very dangerous. If an > RT task preempts the owner that is of lower priority, it can cause a > deadlock (if the two tasks are pinned to the same CPU). Which BTW, > Sebastion mentioned in the Stable RT meeting that glibc supplies a > pthread_spin_lock() and doesn't have in the man page anything about this > possible scenario. > > > > > Lazy works on tick granularity, which is variable per the HZ config, an= d > > way too long for any of this nonsense. > > Patch 2 changes that to do what you wrote the last time. It has a max wai= t > time of 50us. > > > > > So by tying this to lazy, you get something that doesn't actually work > > most of the time, and when it works, it has variable and bad behaviour. > > Um no. If we wait for lazy to become the default behavior, it will work > most of the time. And when it does work, it has strict behavior of 50us. > > > > > So yeah, crap. > > As your rationale was not correct, I will disagree with this being crap. > > > > > > This really isn't difficult to understand, and I've told you this > > before. > > And I listened to what you told me before. Patch 2 implements the 50us ma= x > that you suggested. I separated it out because it made the code simpler t= o > understand and debug. The change log even mentioned: > > For the moment, it lets it run for one more tick (which will be > changed later). > > That "changed later" is the second patch in this series. > > With the "this can wait until lazy is default", is because we have an > "upstream first" policy. As long as there is some buy-in to the changes, = we > can go ahead and implement it on our devices. We do not have to wait for = it > to be accepted. But if there's a strong NAK to the idea, it is much harde= r > to get it implemented internally. Can you explain why this approach requires PREEMPT_LAZY? Could exit_to_user_mode_loop() be changed to something like the following (with maybe some provision to only do it once)? if ((ti_work & _TIF_NEED_RESCHED) && !rseq_delay_resched()) schedule(); I suppose there would also need to be some additional changes to make sure full preemption also doesn't preempt, maybe in preempt_schedule*(). -- Suleiman