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 288A5C4332F for ; Wed, 8 Nov 2023 04:52:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E2E28D0096; Tue, 7 Nov 2023 23:52:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 86BF08D0058; Tue, 7 Nov 2023 23:52:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7342E8D0096; Tue, 7 Nov 2023 23:52:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5FBF18D0058 for ; Tue, 7 Nov 2023 23:52:42 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1F7178078C for ; Wed, 8 Nov 2023 04:52:42 +0000 (UTC) X-FDA: 81433566564.14.00CAF4E Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf21.hostedemail.com (Postfix) with ESMTP id 757721C000B for ; Wed, 8 Nov 2023 04:52:40 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=softfail (imf21.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699419160; 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; bh=0tMdxYkQ19E8j+keuS8GA8S08+TEvYqrlaLVgOfHG8c=; b=4QUGrYsCjVHNSD+mEYxQB9gOR4VxVTU8HHGJB/mqfo+vs8cQxun9JkfsWkf6CAo8OVJr9X jP8FOCeVbqKymfMJjvc+DE2JTOe6DbnVl0BCOySzK6wsJJWkDzXp1EGpz48vueCqEth5vA QxnWEImsHdoGtYeUKbB8Kiv23mF9TDE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699419160; a=rsa-sha256; cv=none; b=arVFTDUzs3x2IzW5wA1zJjNT+REn2Z1PPj5ICcst5UxcRHIQPRse4kqsgUwIhLANtiem/W Vilfeu8aj5Pnnfiss3P7lz0PeOR5VzCDcM/AkRd9LmoLWAsZWlkQnkaCme9J3xsbNgNCFK kPiHT80pNdJepxjeZt0SkeBtkjyxGgk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=softfail (imf21.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) Received: by gentwo.org (Postfix, from userid 1003) id 2E3D148F45; Tue, 7 Nov 2023 20:52:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 2AA5548F41; Tue, 7 Nov 2023 20:52:39 -0800 (PST) Date: Tue, 7 Nov 2023 20:52:39 -0800 (PST) From: Christoph Lameter To: Ankur Arora cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, paulmck@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, 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, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, rostedt@goodmis.org, David.Laight@ACULAB.COM, richard@nod.at, mjguzik@gmail.com Subject: Re: [RFC PATCH 00/86] Make the kernel preemptible In-Reply-To: <87bkc4vp89.fsf@oracle.com> Message-ID: <385909b5-3077-42d4-07ef-7ae915d24b5a@linux.com> References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <549c1cba-5cad-7706-de85-d61376db25cc@linux.com> <87bkc4vp89.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 757721C000B X-Rspam-User: X-Stat-Signature: ec149cupyxrbw7t8m8h4z5q1bd7tizw1 X-Rspamd-Server: rspam03 X-HE-Tag: 1699419160-641390 X-HE-Meta: U2FsdGVkX19iiTCp+tJOxMagUPajFrg6gPq84S3fciWIi24eF77niZqmNQvbE7rmavnx/Vfa2wm7rPA0ndB4EC23M6CjVZp3wo6g7P+FpLKoMjPXxPOGEkjI/fD5UqE4D4ZqDjr6jWZ1hecXeAO4pSymECk/FBUVidm6KG9DeOqnrzw4X7nK+U/bkr6cO1YffkT22XXDfyrLMv0SXu65StBfQiWUW5MYcDBNdY593VkefcKZCMax+banHP//d3JFjlfvuyR6rQnWUAnC3QKumLsyquxV+JucdQAcKUNwF5jwgoGI6p7MHqhnbh53a54fBlOOmQZijvn6t14aVz/WJCsPf/7lHUQPPL8OPgzWk61Qwbf3ZQ4pwP4aEPCSRF1FEM5yrIpyj9t5XglwzJYrNnyeoUk6j5e11BYGnkgB1LaPZPP/YCpXReU88X6sMeFZ7v2PZYlaruzov57UgP8zxWVqY7xh68M2EgVfP8Xia3cIQQEAR+2JHR9eZNmbimFaA6wSATKTnIk6YNGlQ+9xvKr6mriFLY8WefXz/4oSDPCYs5LXpezjnhfcyFKyp8XPTYoIfi/yOuFNtVD2PPridPD51LuUJaUJPCe8xPcXf+eqNPmsEilxQNXdShmjtse9EBbYcEkNMm7Rt96agga/dZOh11tgMZFdwEfifmLtQP/cOAARb+UKZV7ECS8qcQo3PhXCYUuV6MqmlNRZp0Mq+bguiVYBmAW8Y1Ea5aeruzj2ntlv6xZjckriiEOHU3qbDuT+/wq1YBecP+LvhGaL/CBSOyiHVybqcTdz9UNqVJk7Tm+CKs84cY/ri+zbRwVjtqweLVUi2a06IHkoq1Og93dpm0/eacl8Y4y78roW11QVNxq5OodsqKB04uvK36D28im54v57tkVOfD9FZ8KI7DW4kzk5snK3uE9sAkWfXpyLW4EkMyxwzAzvQYVj/6FD1HSwLxN+oLjLh76fJ8O 5JMp58cF aJrgkKO07GhG5bRm5yTJGRUC9pwqlO8kOwc3faAFq6zonQSRgzO0eYynCpF+vmtlrI+TN2xnkInG0wbYK3qWYeMGofzoOXjLsPMytPwms8KwTaj92quOo1yHQj/wf/iB9P7DlKrTM5k84xfwQnqWDRJMjIp9kqwjX+uui4WucNzBQc06UCIcptQTio0dLA6D1QyD6 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, 7 Nov 2023, Ankur Arora wrote: > This came up in an earlier discussion (See > https://lore.kernel.org/lkml/87cyyfxd4k.ffs@tglx/) and Thomas mentioned > that preempt_enable/_disable() overhead was relatively minimal. > > Is your point that always-on preempt_count is far too expensive? Yes over the years distros have traditionally delivered their kernels by default without preemption because of these issues. If the overhead has been minimized then that may have changed. Even if so there is still a lot of code being generated that has questionable benefit and just bloats the kernel. >> These are needed to avoid adding preempt_enable/disable to a lot of primitives >> that are used for synchronization. You cannot remove those without changing a >> lot of synchronization primitives to always have to consider being preempted >> while operating. > > I'm afraid I don't understand why you would need to change any > synchronization primitives. The code that does preempt_enable/_disable() > is compiled out because CONFIG_PREEMPT_NONE/_VOLUNTARY don't define > CONFIG_PREEMPT_COUNT. In the trivial cases it is simple like that. But look f.e. in the slub allocator at the #ifdef CONFIG_PREEMPTION section. There is a overhead added to be able to allow the cpu to change under us. There are likely other examples in the source. And the whole business of local data access via per cpu areas suffers if we cannot rely on two accesses in a section being able to see consistent values. > The intent here is to always have CONFIG_PREEMPT_COUNT=y. Just for fun? Code is most efficient if it does not have to consider too many side conditions like suddenly running on a different processor. This introduces needless complexity into the code. It would be better to remove PREEMPT_COUNT for good to just rely on voluntary preemption. We could probably reduce the complexity of the kernel source significantly. I have never noticed a need to preemption at every instruction in the kernel (if that would be possible at all... Locks etc prevent that ideal scenario frequently). Preemption like that is more like a pipe dream. High performance kernel solution usually disable overhead like that.