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 581CECD342E for ; Tue, 19 Sep 2023 03:21:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DECF06B0494; Mon, 18 Sep 2023 23:21:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9D9F6B0496; Mon, 18 Sep 2023 23:21:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C64EF6B0497; Mon, 18 Sep 2023 23:21:42 -0400 (EDT) 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 B637B6B0494 for ; Mon, 18 Sep 2023 23:21:42 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 865D11CA46E for ; Tue, 19 Sep 2023 03:21:42 +0000 (UTC) X-FDA: 81251897244.21.891F7FA Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf26.hostedemail.com (Postfix) with ESMTP id DB45114000A for ; Tue, 19 Sep 2023 03:21:39 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=T9UqLjel; spf=pass (imf26.hostedemail.com: domain of luto@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695093700; 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=kxF9TcI60H0dqMRajNtQ3h1ZaVkRNMZhyZPCtXkyEyc=; b=lhzNzOhuJdQI9dTYpY6XSj3gCq5SYKTb1OFPaqyqIS3x8mRRwAGD9REVaB4QA4kfo4UR69 LNMJ65TEdZHEcB/kb7qF1DgmvMwXAsMnL92uLqK/+3SqlHLqqU7RbSTf5xwlUgAQLgWxoo 0fKOqtvlv5RymDAlFlo35HXAgaT7+pk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695093700; a=rsa-sha256; cv=none; b=FAUZDWRivN4u54tMzo4JzRO+dOpzXnn4fxWyGSv4A8hLgr79iA4zcw593tZqUqR6WUfx95 daQUuQIBYaeF8PEVD5d41ccgoNse2x4l70PMqofaBMjM1t36PQJAppeq8JrFxwnHzc108o cmImLQFxuS6NYRSwGaX39SKxjqoQk3o= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=T9UqLjel; spf=pass (imf26.hostedemail.com: domain of luto@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 5C77ACE11E4; Tue, 19 Sep 2023 03:21:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE4DBC433C7; Tue, 19 Sep 2023 03:21:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695093694; bh=2LmdUZ93iSSVlvHPq9dbFfq6CmmQx0dj2FhDOilY2EE=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=T9UqLjel250GdB/Fn2eQngGfDU+//WxgXbilQglPIIbh3xV0GsuoisDdzUJ3ox0vN NEb17M//LANRGDt8rLOk5vPOQFLN+WVhr7fPx0707AeU1S4zANOEulyC8nqgyjwUDd EUju5t+k5bmhOWx/ty2qF47/xxbPnWjwDTsLLGAtKdrl9mvv1AOxBUb42LYubuKyLS XA75B6FgrO6+hriGxOoBGm52bi9wROUdC0WkQv3Z4U9V1XQgfP70mqKV9iYfEL9jXP 4EpL/POP4nyGe33INfVceyZ75dTGfNoPZ1lY6ux6xLnutnAH3iP10+yd5NaEIATvKh K2IaDfz0LRrQQ== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id BC0BA27C005B; Mon, 18 Sep 2023 23:21:32 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Mon, 18 Sep 2023 23:21:32 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejledgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdfhuedvtdfhudffhfekkefftefghfeltdelgeffteehueegjeff udehgfetiefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35DA131A0064; Mon, 18 Sep 2023 23:21:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-761-gece9e40c48-fm-20230913.001-gece9e40c MIME-Version: 1.0 Message-Id: <39998df7-8882-43ae-8c7e-936c24eb4041@app.fastmail.com> In-Reply-To: <20230830184958.2333078-8-ankur.a.arora@oracle.com> References: <20230830184958.2333078-1-ankur.a.arora@oracle.com> <20230830184958.2333078-8-ankur.a.arora@oracle.com> Date: Mon, 18 Sep 2023 20:21:11 -0700 From: "Andy Lutomirski" To: "Ankur Arora" , "Linux Kernel Mailing List" , linux-mm@kvack.org, "the arch/x86 maintainers" Cc: "Andrew Morton" , "Borislav Petkov" , "Dave Hansen" , "H. Peter Anvin" , "Ingo Molnar" , juri.lelli@redhat.com, vincent.guittot@linaro.org, "Matthew Wilcox (Oracle)" , mgorman@suse.de, "Peter Zijlstra (Intel)" , "Steven Rostedt" , "Thomas Gleixner" , "Jon Grimm" , "Bharata B Rao" , raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, "Linus Torvalds" Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Content-Type: text/plain X-Stat-Signature: 8ekaqk349jmfkxqpqdy4sqrhaqiofowb X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DB45114000A X-Rspam-User: X-HE-Tag: 1695093699-403360 X-HE-Meta: U2FsdGVkX1+ttB1easWvP2LCVLGMB5mZUYB0DNUIUrST52NQ7z3zHssmU+zHYSnR7/MQx0ho9yMblYzSeqx732Pkt4lOAhPzru4m0HKEzwEdwmctvWbDd6lsRUe/tgz5g3ASSSyd/4gvDkoX/qu6J/rJq5/+xKEBMlscHoGweayfc6pcYo2In+p+Xlx+gvXXspTp0qrOH1SKDRB4ObMhgmWFL0oAE0Gu6DmfHNBEH3NESB8jZBfv9NDWuxm0E3fbIB2JrqiTHM3xIeZf8RWhwXpKWyxOlfwFyO7SILdvXUCBN93EIqLf2JHDPdLDSR3WUlxDp4RUAH6i2dPEqVR/m+jLjQwyDQ1BoHz/tTcZIVK3lAJxtBfsLB+o3/gKjjK04oTZgHIqwW8D3K66U+5VyKIV3zCI4F5GMinibpDBf2ffAuX0qUtyiN0FpTzXu+tZGM7IdV+/g5Cfjc9dYuYH9kN2G7Jd4MOPol+QgALynGAX+z69Ylqmkxihr+bW/JGgFdzojeXLsRv9GfVuwFx0x7SOpy9JcCFIqB4SN6f16zgL8ZPZp3l4/Qb2DwRaEUeIu5vdccGenKiHjlxzHIjH17ucKNybaPaA9ZBAIGHPnxgTfr70igiyBMiqalMLMOVZcvAuJCWkLWfNnM8snMKZeRmXk3mRqIpivzx/Pn1XuGdyKBczubG2AlBhl0BF9naTD8a9GRJGusgbaGAcG1k0Eozd7d7Mnt3D0Kkwd2/QMm8fsCYHkMaoSaGIMsCryypYwqxlog0iF2LUXvt0hzCvz3do/+9Q3AziHxeHgEXb6cHO/R0VUx5DySJTkz6I/mS75TeEhFp+CPzjTJD3dMsM5Yvq5QsOc6YRgBWZKQnMBE5rZJhNYYW3IDxHPFll0p177zn3rzJEFiz3qaI7D/a6lstwSZ0mZFN1eHGme0rne6t/dGJ14hJqZHJgYPYq4HSXFEeZqWm5wQtQggL3mG7 L21Kzmqo 9SE7NvIPJa6vGY/X+4jvXQFy08UtGosQxmTZKlEv8UPw6jOOcbLwuV+gBS4ucYFPURWupJ3bA5SSjDD6GVafCCUdwun63ISZp7loe9ryeVZ+YyeuHfbHhl6zlp+2m5DboBS0tW9ZogaeZrvuWTJwta9ErVQjuK/Gol8cPhP1w/nJb4ZnWuYZMImEG3nbaB0mTvaeWBUp5J0tHxGo/lgCcK7E6fLPqOlA9PfPaAwIYPV4FDq2iZtcXbT2I+JkD4n+F4gq45ebwH7UYxsg02W5Zal2h2DBlwQ5ag7mqqg5elMb+Gpny+5TGDMRITw== 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: On Wed, Aug 30, 2023, at 11:49 AM, Ankur Arora wrote: > On preempt_model_none() or preempt_model_voluntary() configurations > rescheduling of kernel threads happens only when they allow it, and > only at explicit preemption points, via calls to cond_resched() or > similar. > > That leaves out contexts where it is not convenient to periodically > call cond_resched() -- for instance when executing a potentially long > running primitive (such as REP; STOSB.) > So I said this not too long ago in the context of Xen PV, but maybe it's time to ask it in general: Why do we support anything other than full preempt? I can think of two reasons, neither of which I think is very good: 1. Once upon a time, tracking preempt state was expensive. But we fixed that. 2. Folklore suggests that there's a latency vs throughput tradeoff, and serious workloads, for some definition of serious, want throughput, so they should run without full preemption. I think #2 is a bit silly. If you want throughput, and you're busy waiting for a CPU that wants to run you, but it's not because it's running some low-priority non-preemptible thing (because preempt is set to none or volunary), you're not getting throughput. If you want to get keep some I/O resource busy to get throughput, but you have excessive latency getting scheduled, you don't get throughput. If the actual problem is that there's a workload that performs better when scheduling is delayed (which preempt=none and preempt=volunary do, essentialy at random), then maybe someone should identify that workload and fix the scheduler. So maybe we should just very strongly encourage everyone to run with full preempt and simplify the kernel?