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 8681EC4167B for ; Wed, 8 Nov 2023 04:08:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBDFB8D0094; Tue, 7 Nov 2023 23:08:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6DEB8D0058; Tue, 7 Nov 2023 23:08:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D844C8D0094; Tue, 7 Nov 2023 23:08:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CA00E8D0058 for ; Tue, 7 Nov 2023 23:08:06 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9EDD5160A0E for ; Wed, 8 Nov 2023 04:08:06 +0000 (UTC) X-FDA: 81433454172.24.5599F36 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf29.hostedemail.com (Postfix) with ESMTP id 0B8A1120011 for ; Wed, 8 Nov 2023 04:08:04 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf29.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699416485; 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=KAcQou51PHycZkraJaavPj4B9QYNQCj/W84ReF7MR8Y=; b=Wlh4YmOy5lX9+WVIKnbqGL1x83p+vFDOT8CGahGyP135zlCAyzmFTuw5iYziQUJAOpILTa JOQbOp0ugG7xMUTcY70BIBF+FE5tbezXCglvYbfOBQSYsCAHdjs7cNBNpsI71RWMqEQdkY 6JMArkwPQOB7kiXEIwq1MKgZDgz+8jU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf29.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699416485; a=rsa-sha256; cv=none; b=bG4bgyy547iRHYuV2/kGqYYYjHgtuSRwHp5M8Jd44/eRo48VndDRr/P/+fl8XC2oIIDD6y 85InjTbSQfcjz698EKxq7ejkJjbPbLMhUNC2DZuPXAhQqu408jX4qF1i05FEMWdTjJ+LsD GTxbrZnCIk+nzJW4wQ60bFBdvXJG2Jw= Received: by gentwo.org (Postfix, from userid 1003) id 8A7C048F45; Tue, 7 Nov 2023 20:08:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 87CFF48F41; Tue, 7 Nov 2023 20:08:03 -0800 (PST) Date: Tue, 7 Nov 2023 20:08:03 -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: <20231107215742.363031-1-ankur.a.arora@oracle.com> Message-ID: <549c1cba-5cad-7706-de85-d61376db25cc@linux.com> References: <20231107215742.363031-1-ankur.a.arora@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0B8A1120011 X-Stat-Signature: kwebkohrxfj7gxd9od1x416nxeaaanwi X-Rspam-User: X-HE-Tag: 1699416484-759828 X-HE-Meta: U2FsdGVkX1/bY4L5z3jqfNNTs5MASZyelh90YqPA44f/dZ0Bi1ejB99Z5mqmQD3wxx7NKDZIjLH2DBWzwE1KvcJJHMKDq6hXlXwsrnOpvqH2KfNZkGX0adUf/ONjyZQcTcRcdj6U6xyXwjqxh8k2lABipfx5iGpfoP8p/v9w4PZZUIrA68iFEXnmRW4/6A4ljCFUbqHNofYUqG0/oU+OCxCoKemHFc7q8vMR/Ye+gWEfLbeY6N5b2Tgw3Lp0TNHPAh1tdBbooUJVMYemrChsZ5ptff9h613IttLcATlwHMI5egseqKNe0hbcJSA9x1Q7pw6giXRIBtLIxy9+aGelBLdm2Iy/vLngBvT7v1CxOZB8MYySKAJMWl76jv3NyYnd+0ISt3AQR/JetL8aV54QDyXpaXI7vtaoQVMWhboPUXkRZLKRsdHBOA0klHv5/AAgAxnzJ8l/qwYyX4onGELJ3INze8LTZSkU2+7orl03JJwAXrQlXSiNPaVqgadKvxipyQpYa/yhHsItQguXI5b3K3byXJl/PYqXpghrL27mzqB2DPsiRZ3r5MHTrjlzt+MKsZpJMTyOZ+sZlXtoI4ZLQKneCfSaXc3/MKHKNJ+Z7KmshesosXQldmq7ws29EIEegKxJIzZzzsJCRD+6HS9x8zS2+FhC58oFalQULqTe76oLwa3GrifIinAeKmW+wZVemaQXmuZiwvajImkCC9NIRBpuo5mMJbzhS8b94lQSDv9gLJNCv91HuYkAznYt9gIQ54hWBi07PaOlsZCP6pkyFbyzbW/53xInh0JuzqnQawWSTYrDlFxH3eflD9eo+kX5yyX2iHGr/m4lZxQrz2OMSS/2npYxfOsFAsHKx+NIFT9ssnp6Bh7xUdaigGytWK73fnb+MjYfAQ0ZKch4bcFCefJwRhqqgnDPlGMG2mJa4vIi1LtHUi53T/odHDw0R06adnKqUENfH9h0zBtWmHP XUScNL6o Xe1b1Btp1/rc3ord0nQf3NHCZKX0gHGub0opis4ubOtEc2zsU+oIknAzRiGgmnNIkSzdKqKJCF5N9NsjSs8Ntdm5Oxakcw9rdGzhwQxPu5LkfKa9rGaEgIlxB3HjPlclwRWmU05XOgdBVSFk= 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: The kernel is not preemptible???? What are you smoking? On Tue, 7 Nov 2023, Ankur Arora wrote: > In voluntary models, the scheduler's job is to match the demand > side of preemption points (a task that needs to be scheduled) with > the supply side (a task which calls cond_resched().) Voluntary preemption models are important for code optimization because the code can rely on the scheduler not changing the cpu we are running on. This allows removing code for preempt_enable/disable to be removed from the code and allows better code generation. The best performing code is generated with defined preemption points when we have a guarantee that the code is not being rescheduled on a different processor. This is f.e. important for consistent access to PER CPU areas. > To do this add a new flag, TIF_NEED_RESCHED_LAZY which allows the > scheduler to mark that a reschedule is needed, but is deferred until > the task finishes executing in the kernel -- voluntary preemption > as it were. That is different from the current no preemption model? Seems to be the same. > There's just one remaining issue: now that explicit preemption points are > gone, processes that spread a long time in the kernel have no way to give > up the CPU. 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.