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 DB204CD54A9 for ; Tue, 19 Sep 2023 09:50:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45E9E6B04E5; Tue, 19 Sep 2023 05:50:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40E8D6B04E6; Tue, 19 Sep 2023 05:50:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D6DE6B04E7; Tue, 19 Sep 2023 05:50:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1D67A6B04E5 for ; Tue, 19 Sep 2023 05:50:02 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D0992140BD8 for ; Tue, 19 Sep 2023 09:50:01 +0000 (UTC) X-FDA: 81252875802.25.9003401 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf03.hostedemail.com (Postfix) with ESMTP id EE4BE20019 for ; Tue, 19 Sep 2023 09:49:59 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PcvwpiCL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf03.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695117000; 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=EhcN/lwEEoB6hHokS07vdHgzChk+CLg70p3seLqswTM=; b=C+orzzDgOTphGYQVHy8YwHZFGTl972Dh0gMSLwKJVWPUBFJWni+V4qf4t7dtjr3WuzXUNA ZdNVOUbDjvFJ/u/TXaRqtLved43qn74yBd/CjeMa+YwEga0Sf4Vzd7sS7wwFUbA0ND6scc LdsfRFRROVPbQEC75+ZiTmqqCIb6F6s= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PcvwpiCL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf03.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695117000; a=rsa-sha256; cv=none; b=spvGXcEykGExxdPFShM44e4YGIYxXFgjZAw8Gyzi3lffZupi/CkECtlAShTF2F6LQlYuqh iDmI3f33cJagdGM2VQwCAI9PtjvE/v857+2Yl5/0vdA4yqLs/YqlU+K2TgMaUObXPJCsft xckxIsNJb0X/xXtrSuPB1F7Yg6em15Q= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4018af103bcso36388765e9.1 for ; Tue, 19 Sep 2023 02:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695116998; x=1695721798; 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=EhcN/lwEEoB6hHokS07vdHgzChk+CLg70p3seLqswTM=; b=PcvwpiCLr20ThzviDOInYILNGrTXsrYdlUnVR7K1AwbeBeE101QLFsbmAFnyS4m3/h kHOxPhAbYO066GmB2XkAgg0wfdWG6iT+1nMEAgc+CjEyK32yZu3kpqRUpeAa+gCUH5po YNisC2vfggI4RKWxzEnV5TgRm0Q97H7hIG177RoXIrsD6xiWYISOK5W1CqG9D0kbaGrH nssAPCR9U1j2wz3JC0e8mDlKJIYHklgmNeamQsHTTqGtmcvESFcvU9gT9z7GeEA2wOIB 9Jpw5pdqPZ62Nw9KxzXgot6rZ6xeLzsr/5iWFT4xFvRFkcTh35Hq8Ram3NZUisqmCGIZ 4Yng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695116998; x=1695721798; 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=EhcN/lwEEoB6hHokS07vdHgzChk+CLg70p3seLqswTM=; b=Y0SlmKxFSROyYrzBUKYDJ1DS5WTv/mHpuZPMGBTvH4ZBKcPJXumhhzJLuGhZ5ZOs9j NKa1YuE3VlykpRablNGo/ssoyguEq+1COmNT+2UHDMd7N75hML1TRrT/IBkH7tTvtXp0 uDjh4RLLESHYCwZAEQ1Hq8rqtOV4f87Xq06ifFVHkDrUjxSBelMhxoyDzou5ONJ2awOc 43+rP0nVChT8xBcd+lGgPMJDihxUPv8pttCBHttOla7fs0f7Mp/8aT4hF4Eh+zCM8gq3 2BM+GjjbXBZb6RDJ5bEz0I1vERCXPlZ/8CsqHiWL/C903/8zbd4b4gXRO43YnUgoybO0 gZkA== X-Gm-Message-State: AOJu0Yzr5kxHS+tVdgiNbnlqqhkTS7ZcgeZve8ticNC6ZfHZuOKofUaR Go3tVbrzHJLgQp8GdODmUJY= X-Google-Smtp-Source: AGHT+IESAxiN5Y9yOBY1Na857XazpwqoJPdlaVeSUc6fqY3EB7N3Bi635X8rAsPrIk+tNBFf/wNzDQ== X-Received: by 2002:a05:600c:3488:b0:400:5962:6aa9 with SMTP id a8-20020a05600c348800b0040059626aa9mr1564056wmq.11.1695116998275; Tue, 19 Sep 2023 02:49:58 -0700 (PDT) Received: from gmail.com (1F2EF265.nat.pool.telekom.hu. [31.46.242.101]) by smtp.gmail.com with ESMTPSA id b14-20020a05600c11ce00b003fee8502999sm17525375wmi.18.2023.09.19.02.49.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 02:49:57 -0700 (PDT) Date: Tue, 19 Sep 2023 11:49:54 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Andy Lutomirski , Ankur Arora , Linux Kernel Mailing List , linux-mm@kvack.org, the arch/x86 maintainers , 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 , 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 Message-ID: References: <20230830184958.2333078-1-ankur.a.arora@oracle.com> <20230830184958.2333078-8-ankur.a.arora@oracle.com> <39998df7-8882-43ae-8c7e-936c24eb4041@app.fastmail.com> <87pm2ewmcy.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pm2ewmcy.ffs@tglx> X-Rspamd-Queue-Id: EE4BE20019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 5h81q8oro76jhhmz77pkcsxueks5ey8x X-HE-Tag: 1695116999-272653 X-HE-Meta: U2FsdGVkX1/pMTFufF3PiHJCvwqFIRTclVARzOVr7yIUdbwnY9t1U3iHTscpmoq/Dhbz22zC19cAYYsSeotDrHOWov21eOBX4s309KP2yyDEp2Kw2ah0tlynufOhDtss5GeJPWzrN5hYYVrPyJo1ND3hwWbUDp6uej10Mt+XYFGPqRRObHfa8LU2+QfiXxiAccr9lfcabKHbCpmEm5q84sg5YbOiXTuS8ctvJC0dj/CKMMeSi/nxGGCXBvdY1f0DXOe5KkGgX3WTnOBPo4nyS1UwPQ8xXo2o6HCOMFpelDN1V0tbx7afgc5bs0KPG62Fk0OMsg1phOMZElyqcbVp8DYbFL1SyRLJRalUp0C6oJ6vndJCLS4x13PkNRlP/nPo+AIhTX4OdUDUkqIsVd7VucJteum1aIfRO6hODVg+S/aqYDbVwxYvM9fRLptm8vOcWmbOD56zfUkJhcF24Rcym+CiWmAM2+phKo0XbqhydqKlk6HtcSYkB8T5n2VO0XjNZsmI1Zv2gxEa1C3ouSedseWaQr0IK4X27rqUvko42CA6A8pdeFZYYFaPOfx38PEJelNtj8LBmnGfdlgkSdO/SMAv9KTq1k6dXs0YKIPv9xxORP2iGdKNU+6/8NrT6eZBwaoaPg7+cEKcyOzjWRqJd4jh+sXNoXVjQuDNOAgNXcTTXW4r7bpQ/uRLk+EKWjFxgl3DGbCHZg/JC8tq5jbagRtYXw3CSgCL4+1MYB0+Pa0vDZKb6PDiaw110usjrsIvBZcwGPX5PzkzuscAaoRbCmgWblKeIJuPjEdRizvxDU1nx6J4AKj64Eg7i1XVYLaGRL0eTSqqHKO+CUX8lVqnd8HN0F9wpx4BEi3nDoIvIoVKbEQBIlS6LaCO1VsZYYEeg+RCja5rErHPW+BDvkVGEuh+5hzXVFg5owS9PJ/G4GYFDj5e7C2ILUIJo0+dp+YUUdve5qXwfmLcqifHeI0 5T7NIZe1 bIT5eZW7/l4GugH+oSyOU5jiyCgo0/2fFdG7G8LJ14kfOtsVBwvLnQcXYSNq5THwUPXJ+ggQlgbSaPrvXiypTQvkIG2DwrnjlAtwozAfvrdKDewK36GKPD/dq1baFaJMAHOGPF9A5oMFYwTKTKXJODvagSXML0iJzmfm6KGwhIEz5QNcIs+9XJlvM6whpopNg634xbF6bxYMcsHYreIW1+bgcr0/D0rHHUOAJOm/afryLGNhqJn9dSFXVMiJJRxvk5W/SKZkkuC5wvrFE+GIpUbOCluo5VzYtqbd/58K7ZZ59wiepGjQu3a5PFTWJzM7Ib5h0bzSHydJBlpSKxHZOhqaLF9btX6Fr1Efz+NINlDQ60SRkkoqLP+4l40MtOjw46om5ZOW542oSl0ZMFZuG7fni/t+HZWRodoHnQPD8FYODV7uLuno4gwjMPgWRzoLpYoXHqmYHGybw9+kDzrZiJb6CvKpWd+8iYqtDc4KGAq56I7PGl9LOYGVCWX4nmTLbdS7GavYCNXLMa7FHf6nxg32YIz4G2JvxEaLJZKIL9KYL/9CbYSeocxOwIQ== 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: * Thomas Gleixner wrote: > On Mon, Sep 18 2023 at 20:21, Andy Lutomirski wrote: > > On Wed, Aug 30, 2023, at 11:49 AM, Ankur Arora wrote: > > > 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. > > It's absolutely not folklore. Run to completion is has well known > benefits as it avoids contention and avoids the overhead of scheduling > for a large amount of scenarios. > > We've seen that painfully in PREEMPT_RT before we came up with the > concept of lazy preemption for throughput oriented tasks. Yeah, for a large majority of workloads reduction in preemption increases batching and improves cache locality. Most scalability-conscious enterprise users want longer timeslices & better cache locality, not shorter timeslices with spread out cache use. There's microbenchmarks that fit mostly in cache that benefit if work is immediately processed by freshly woken tasks - but that's not true for most workloads with a substantial real-life cache footprint. Thanks, Ingo