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 98CA5CD54A8 for ; Tue, 19 Sep 2023 08:43:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 342D46B04D2; Tue, 19 Sep 2023 04:43:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F2726B04D4; Tue, 19 Sep 2023 04:43:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E0E76B04D5; Tue, 19 Sep 2023 04:43:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0E08B6B04D2 for ; Tue, 19 Sep 2023 04:43:16 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CAEAC1CA8C5 for ; Tue, 19 Sep 2023 08:43:15 +0000 (UTC) X-FDA: 81252707550.11.7750E4D Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf24.hostedemail.com (Postfix) with ESMTP id DB3F2180027 for ; Tue, 19 Sep 2023 08:43:13 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JhjRsNkc; spf=pass (imf24.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695112994; a=rsa-sha256; cv=none; b=HToKjxFvSNFt7+sgSiMybs0uSoyeRKCV4grg+LkhyApo2hy3k5slR1+/g8CRKQ2jHO5OgV 3NPZFSzRlCNs4Jc3D4JJnBOZiSGkhFiHygfPCHDAXwIYe9ManqThaUgtgx2UK904lOAzoP cokz9puWwnNA5n/KLLartqTF6DMWvwo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JhjRsNkc; spf=pass (imf24.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695112994; h=from:from:sender: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=3UHR2InkgMMl7Hda2d0jV09VYBGVKmUXlu3if1+WOa8=; b=wWrd3D0H9w7lS4UT6E/bffTLlcQA16Np6bkK5MRRfUw0jUgeQ/CKZYQ0PUo+fM9wHcMejv sYyMtoC5/U/qexdXnj3FzGaSSV+5aZAUB/wejFjZEkdqbJY4Iq+Ez8QXJSy0katf2F0L/K Cpn83eCs9+fcPeQYfn4RaA9LCI5lxnY= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-50307acd445so4230616e87.0 for ; Tue, 19 Sep 2023 01:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695112992; x=1695717792; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=3UHR2InkgMMl7Hda2d0jV09VYBGVKmUXlu3if1+WOa8=; b=JhjRsNkcFSW03DSuyRMyZEuufaCFmY9pbI8uWtid+882quH1xDBRSW3pFnHhzHhUW2 ZAABzrndom7DGIbRswMp+jFzoEZOvKnMqBI1a3Awd3lFCiTAqXg3fIejX6sT7B548scj sQQPkoJArXH4DT81OXOk/4cUoBWy5EBR66BlsEx5AO1pve2eHcIXk55JTurvZcbtecFt oTFTU0qpmzd3AHnU/t6tfLb8UV0HErHzz6LR3eSKirOeE7YFJsF6ujLfusfKvmN97x9s LtKeXd0R1S4beQLixw8Q50p4HifXYEW5OL9mRQA4Fg4Sh2Fmy6akASNT7djxigAQu9DH 0E4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695112992; x=1695717792; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3UHR2InkgMMl7Hda2d0jV09VYBGVKmUXlu3if1+WOa8=; b=MN0RyYzkIJ+Zs2m8tp6BU/Js5e3uiHPT/S03iZvhWmluUZ10nO5rjAV10sv/cuk+rS pwRoVcUz1/5adOWOv8BzVt+q09XxaTbckuwObUSjhXCGSo7bUwjBywYvHok4MHLyt2BF TLHHPHx47+8hhYj7fTa/1Ead+NfnHtyNlu+Fe7tca6zYt1NFlDc0Zly4DgMoRlsaw0eM sdo2YPI/c+R5J+ApfeX6UeQzSnt6Rf3BNzecE+jdgVK/gDbFGq0ADoRrjk9KrbnrdSyN +kpkDenXm8oNhBWR5LFmE7rBNodsNr/uMJ6iYbA085tya3gFeZ5nvfkmFAxhPvc/zbwq /Bdw== X-Gm-Message-State: AOJu0Yzz1DoSe+LF3Xje7DM6RARrkOZSQ5NsN+yTE9CVwsSFoR8dI3hM mZ7zqWHibOwLq4e2/EvdIHc= X-Google-Smtp-Source: AGHT+IHDIYI0ozuHYLl6CdJx+c7nxfQSHLLeQ5+F9gl+D3iOdIMHKn3+g5eZ0l1UKZ1Cdx4PMoIHmQ== X-Received: by 2002:a05:6512:110d:b0:503:17d6:7dac with SMTP id l13-20020a056512110d00b0050317d67dacmr5014224lfg.42.1695112991707; Tue, 19 Sep 2023 01:43:11 -0700 (PDT) Received: from gmail.com (1F2EF265.nat.pool.telekom.hu. [31.46.242.101]) by smtp.gmail.com with ESMTPSA id l12-20020a1ced0c000000b003fed4fa0c19sm17344003wmh.5.2023.09.19.01.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 01:43:11 -0700 (PDT) Date: Tue, 19 Sep 2023 10:43:08 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Thomas Gleixner , Peter Zijlstra , Ankur Arora , linux-kernel@vger.kernel.org, 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, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, rostedt@goodmis.org, 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 Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Message-ID: References: <87edj64rj1.fsf@oracle.com> <87zg1u1h5t.fsf@oracle.com> <20230911150410.GC9098@noisy.programming.kicks-ass.net> <87h6o01w1a.fsf@oracle.com> <20230912082606.GB35261@noisy.programming.kicks-ass.net> <87cyyfxd4k.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DB3F2180027 X-Stat-Signature: mao5yndtfpxkksikihjyxege55foeke6 X-Rspam-User: X-HE-Tag: 1695112993-352824 X-HE-Meta: U2FsdGVkX1+ZVc2ju5IpdB4gStHxRqf5iqE11GickgkvYnMn5OUV2nGsFZMlcAmJh00pxOsbllr4qiR4+M6emctN5aCWXrk2laiJkn1EW6ylgAldmcYukMWeyFkL3MtCVbKBYbewSkeYaIyEGd31NbxyWO1sHdyHxpWJvbxkZCrs2+eHu2FpzM2ry5TLroGn7/YATWpjicmMoX6yyKHwookF1u5ktfeAnLwcY7518RfLw4W8I1sIdnPPq/qW46dVihDlGUp+jc593p/xyNFmU3Iy5fwNwuPobe9qbKQUOdNjdbuDUfzihD4TN7xlfpWC/3op1/OEo8gx2HMyfu3nWdLsyFXyqJL4V9dO5ds/Zw2jHqrgdeiS7mXMEo8WjdmS0gQYKW2OzoogYUwaDC9Qns3FwUFYBOKdOLzGTgHVrYmHwj+eTY+hpO4sC2NT/D07ZZpYDIhe81QRs+YqFio9F5yF47SncmYlSc5SSmWDUU8GCPzg3ZaFN1sQrv5pR8qmmwctcKmsbBKer+60Zb2iEKM2dd8FilfC/0gH55ScZrFEDRNPOvVaCV1kcqcx9mu9qoTnJrmNt/bwmoCz1B4tp8B8eY6xPOVPkBVRzc2WV0cwTT4zcNIynGCVWNqKhuivmHyOUiBlE4MMCf/r8GU5EWv+BP7Wn6v7EPEfaLuTjDjRal0KRn4+Wg1YQ8IE/hmrA/DiopL6tNn2kapuxiDCjY4lkWGUyBBEHVdPW2hZz0e6CZLBBQScXyb3NuYbqq+DjN1MgmSJlKE+Pvi1X4P29CZIxqHBiiBKVBeSTBF+Vx+P/mXegp4Kx5M58cvRXIvJURrjkAriKIyetRjGtssOmDEJBYXDZ7fmS3WIkTgpH7oSVXL2MBMVk0zqyy8zkIgftk1IAi4EVL30gEdzKssAZlf8z4VTzHW61M/gInzTXOgzAOugx0PvfOYyjLBllevZcUBlzecVdd+SL3ASnXy sQQD+sGs DxZH3bvVnGPnzqAimisESERWiAbQw6e9Tvm621OFcqO5jyO3Mm5tnyAvQeI0cXs0zZK/OgHt69wj6OFHKsdRevTDzuGn2CWXc11w2JcIIgYQfgZ05tFp4tpVi3F7FjT4tR/ZJsWyHkPmOBtbW4W9qpcV68/4Hex5gjfZ4zoem5FH3VCdhqYTGOlT9wD+uiuXlNVuVp9Vp//4O79Seh622OADvnb4j6sP8aCLoJjOnfk2cP/IXM49ghz49qsrTTTsjSwVm8uwhA/CpgS2TbkEVF/QbU6P9CG8rKcRB2PellQOEZlkzKYTA0gb+G0qQd8F5Xr/z8dmgiQ6snXmmzuNSEjsHIKN8T8W9e6GZlGFWiEvDemA1KsixLPekkxwhRLWFJnaCUdSEhx3HIGdn1LU3E3e3mLb+vMc+odNb4MqBQnlUrkk+C2i1MLDjPlELfU8+GMiSrUrE5/rCWp/SuIbRyQp0lCRiUFOmgXfNNy2D6GdFk6iPzGtj7TbrvEXY5b98rT8xfMrKJrVsXyAQ8FT/2J+Ujr9KkSSIZPAMwp/8yp/TSZBuwKUzf0EL14bbu6pCtDAwf9wwyipZHTPboUaG+30jsaY8k5SQI3IbbY24Ygfv2gv+uUlziKOWeg== 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: * Ingo Molnar wrote: > > Yeah, the fact that we do presumably have PREEMPT_COUNT enabled in most > > distros does speak for just admitting that the PREEMPT_NONE / VOLUNTARY > > approach isn't actually used, and is only causing pain. > > The macro-behavior of NONE/VOLUNTARY is still used & relied upon in > server distros - and that's the behavior that enterprise distros truly > cared about. > > Micro-overhead of NONE/VOLUNTARY vs. FULL is nonzero but is in the > 'noise' category for all major distros I'd say. > > And that's what Thomas's proposal achieves: keep the nicely > execution-batched NONE/VOLUNTARY scheduling behavior for SCHED_OTHER > tasks, while having the latency advantages of fully-preemptible kernel > code for RT and critical tasks. > > So I'm fully on board with this. It would reduce the number of preemption > variants to just two: regular kernel and PREEMPT_RT. Yummie! As an additional side note: with various changes such as EEVDF the scheduler is a lot less preemption-happy these days, without wrecking latencies & timeslice distribution. So in principle we might not even need the NEED_RESCHED_LAZY extra bit, which -rt uses as a kind of additional layer to make sure they don't change scheduling policy. Ie. a modern scheduler might have mooted much of this change: 4542057e18ca ("mm: avoid 'might_sleep()' in get_mmap_lock_carefully()") ... because now we'll only reschedule on timeslice exhaustion, or if a task comes in with a big deadline deficit. And even the deadline-deficit wakeup preemption can be turned off further with: $ echo NO_WAKEUP_PREEMPTION > /debug/sched/features And we are considering making that the default behavior for same-prio tasks - basically turn same-prio SCHED_OTHER tasks into SCHED_BATCH - which should be quite similar to what NEED_RESCHED_LAZY achieves on -rt. Thanks, Ingo