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 2029ECA0EC6 for ; Mon, 11 Sep 2023 22:20:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 726A86B00A6; Mon, 11 Sep 2023 18:20:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D6776B00A7; Mon, 11 Sep 2023 18:20:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C54E6B00A8; Mon, 11 Sep 2023 18:20:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 460C86B00A6 for ; Mon, 11 Sep 2023 18:20:08 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1814F1CA6DD for ; Mon, 11 Sep 2023 22:20:08 +0000 (UTC) X-FDA: 81225735696.10.9B51749 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf23.hostedemail.com (Postfix) with ESMTP id 11931140006 for ; Mon, 11 Sep 2023 22:20:04 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of "SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694470805; 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; bh=VbowMMH1Y90E2Vm4NC1LB4cWu8S7ybltFMah0zeH2T8=; b=Yko9ifSR4AkxcsQcEoBu8BBPL3/jMfZxHL1higERpGec5I6pWmc5chC/KjZ7l+RQmTRjcx H3hWHdNbvpCm+ij5CP0DAUL2Vi4g5U1+QvyI+Z4KZuG/EEKs35znCsJhCER6pVXkBlv4i3 rwqEzmjSDiuUppBdkC+PfWk6C8TKsyQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of "SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694470805; a=rsa-sha256; cv=none; b=cgh8HMp097mT48+cwhtKvqhtUdFqKvRFRxxDrOID3gftkq86dVFurzc3vkFihsyuGzSVnk YQvwgjuD7W2PafMiI+2DlNZwcMcfhXLfttzS5/AgjJzwgQgY4u1/O1M+Ktth807dKatJG2 0NZOMfIOIcM1P9zf2x8JUy63xi+Q2aE= 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 8D1EDCE18A4; Mon, 11 Sep 2023 22:20:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABBB5C116AF; Mon, 11 Sep 2023 22:19:56 +0000 (UTC) Date: Mon, 11 Sep 2023 18:20:12 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Ankur Arora , Peter Zijlstra , 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, tglx@linutronix.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Message-ID: <20230911182012.7f1f35c1@gandalf.local.home> In-Reply-To: References: <20230830184958.2333078-1-ankur.a.arora@oracle.com> <20230830184958.2333078-8-ankur.a.arora@oracle.com> <20230908070258.GA19320@noisy.programming.kicks-ass.net> <87zg1v3xxh.fsf@oracle.com> <87edj64rj1.fsf@oracle.com> <20230911124856.453fba22@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 11931140006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: fae9kn548t7d7tdw175wgcfss77dewjs X-HE-Tag: 1694470804-823496 X-HE-Meta: U2FsdGVkX18xN6mnVPlDB+t4fbk+aLhfQHUmSdWxZJ8sdSoH3g7gXWpNAoGxg+Zqri4uZ8BGc198lqacHo2ykYfZSsVlTrc7L9tYP9Tzb6DDf5nx4uuSPNO4jjUhdRDo5VaX98B4TVDDfSer1gT43qjm64EkjEnEmQ7Hn64bJE6kYA8FUJpoRfnz5vrAgJVITpcmALtBnq9pog+9Xb+szxasJ8UnBVHVKvADq02Rb0R5QzA6CExy3U/loFK9gqq9XGOKq0I3a9sSuayQfENxk5qUe9hTLSFiYJFICzoJukkw0TaS6Z1aSRnEbPLb1tzkv4V7uuF6QqJXPxckbQa141JH4dX72h/ZlP4dx/9ANbsW5lztCh5hlJBpXBL9RqH85H6fZQHqSULNAfyptiTTJRBgIOITvu+kpO8YWN/qn2tDsUZ4KlpfzC/4NzxryJWbQqTjH/hJm1wF0lyexuWzKC38HQ/xENK37kol6SAFrYg6L7SoYFxbAL0goLZXz8B/CER3Z2PZrA2l69ltkOKe9NW/JJKSjbnEkOT4urFSVIfo2SvQ/3z1VgIRdoak+frvOxl5mv47898Sdk/i1A+FRiC8vZIvTOHZYbXB/32xSiw7/5ydyoqyKjofFKaqu2ZWhqWqxGcNWgiHbK8R3jJOWbZH8HzxEl6COOY/Dm6shSmvY+NrMz1+F6TeK/eiKXXrRA0ayW/U4Ext7uE9orcVCWKIPfOkFbYLqiSwTxRGMU5TOmjoES2e8S4HrOLsD2OPp9e35GG3hpzKb0F6crTRv9CJUu+ghI9uFP/Dmij7du0rnjqAh5lFfNQD3qdphygIPCsf7CwjyeLIKGVpRNCrAU7ZUrjp7Mk52wwiictgdWf/w3Qiwcy8U1hiSGT7hKuWmwdAc30vDy07CJSM/2/VyCZOItHFME7/wqih2y8kurT2Cn0cUWWzc5Y15Tl2ab1bgHF5gUhOBirPIhTxJ5f O37VUi11 bPOuq87AvQM2FkimBWYbAxzl3tMq9k5luPC/zpSdJ6Hz+K6IneBiwJFAvZ6l3S91PFTFm1U2USEP8Y7wWynTk17VlQxVFe8IU7MaDxtMPw4FUUcbzvix/QmK2Ynjz++RYzyEAMslvIjj8dS9Wb0ZnEfQBXj82ht3IePChINhoCSmPb2SGORLmUwggsCqgS1oo4lt6AVN4+BhW70CzBSQRbnOdldn/OxUndRrtTQnXju6SxA4ruHQkEd+q05ioNjIHfrmuf3r9Soh+PTJlZoUFK5s9WdS7U5NxtDyyHbo9zanbFDGTy/5g/2WImiKBui/kgSXzA3QRA8sQ7E87qLumsiVCSUMHHOxsQoit2f74fkY1Zupgu5BQ1hgjlpoRaOcr1/zHhPN5kELyFwIwJUIa2zyEFyg5+MyFnZfD6S5/jfnt82idKrfj+yGhtaeRG6Wf1qKj8ZjhyUSjwk4= 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 Mon, 11 Sep 2023 13:50:53 -0700 Linus Torvalds wrote: > And it seems like it's actually server people who want the "no > preemption" (and presumably avoid all the preempt count stuff entirely > - it's not necessarily the *preemption* that is the cost, it's the > incessant preempt count updates) I'm sure there's some overhead with the preemption itself. With the meltdown/spectre mitigations going into and out of the kernel does add some more overhead. And finishing a system call before being preempted may give some performance benefits for some micro benchmark out there. Going out on a crazy idea, I wonder if we could get the compiler to help us here. As all preempt disabled locations are static, and as for functions, they can be called with preemption enabled or disabled. Would it be possible for the compiler to mark all locations that need preemption disabled? If a function is called in a preempt disabled section and also called in a preempt enable section, it could make two versions of the function (one where preemption is disabled and one where it is enabled). Then all we would need is a look up table to know if preemption is safe or not by looking at the instruction pointer. Yes, I know this is kind of a wild idea, but I do believe it is possible. The compiler wouldn't need to know of the concept of "preemption" just a "make this location special, and keep functions called by that location special and duplicate them if they are are called outside of this special section". ;-) -- Steve