Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
References: <20230830184958.2333078-8-ankur.a.arora@oracle.com>
 <20230908070258.GA19320@noisy.programming.kicks-ass.net>
 <87zg1v3xxh.fsf@oracle.com>
 <CAHk-=whagwHrDxhjUVrRPhq78YC195KrSGzuC722-4MvAz40pw@mail.gmail.com>
 <87edj64rj1.fsf@oracle.com>
 <CAHk-=wi0bXpgULVVLc2AdJcta-fvQP7yyFQ_JtaoHUiPrqf--A@mail.gmail.com>
 <87zg1u1h5t.fsf@oracle.com>
 <CAHk-=whMkp68vNxVn1H3qe_P7n=X2sWPL9kvW22dsvMFH8FcQQ@mail.gmail.com>
 <20230911150410.GC9098@noisy.programming.kicks-ass.net>
 <87h6o01w1a.fsf@oracle.com>
 <20230912082606.GB35261@noisy.programming.kicks-ass.net>
 <87cyyfxd4k.ffs@tglx>
 <CAHk-=whnwC01m_1f-gaM1xbvvwzwTiKitrWniA-ChZv+bM03dg@mail.gmail.com>
 <87led2wdj0.ffs@tglx> <8734z8v1lo.ffs@tglx> <87edisibrp.fsf@oracle.com>
 <87ttrothbb.ffs@tglx>
User-agent: mu4e 1.4.10; emacs 27.2
From:   Ankur Arora <ankur.a.arora@oracle.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ankur Arora <ankur.a.arora@oracle.com>,
        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, rostedt@goodmis.org,
        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,
        Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED
In-reply-to: <87ttrothbb.ffs@tglx>
Date:   Wed, 20 Sep 2023 21:16:17 -0700
Message-ID: <87wmwkcga6.fsf@oracle.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?kXHGjwSSlxmb8pP9ekIFqipvOxTx3pphxodOLjkTUYRFiSBT1l38KFJ6ZwOY?=
 =?us-ascii?Q?Md57eKAL5OzNiyw3ICqKE64FVzqs08ZGFCX+6DcMLkRK93bfmmXoiAjIWF96?=
 =?us-ascii?Q?Il3XB1VOmbGMAfxjfHY5ig1Hm1s8W7JUC0sMnjGrCyuwMX3XI+1y17hDjNV1?=
 =?us-ascii?Q?oBJMmOx1IhRWPETvyUH/smh0pNcyHWfA3iO3tIdPq2tHGKVdSRhCMePQVs3N?=
 =?us-ascii?Q?O8uWL28n3R8dexCwS3FZosgMskDpFT9+vDsaYQNYyOxQkwHxJoEGUYH11ztb?=
 =?us-ascii?Q?dpAlTVlMDXehOgLJ4BkvQI3bjugRonNoGGb9f7NMy8/McbRuN6N5HdfkX2z9?=
 =?us-ascii?Q?NsXKmtj1EPbHJ72LEhDeIvS9bzEhKIOVWKvWAGiowcCn07STdwOkAiVjgMgX?=
 =?us-ascii?Q?f5cEnCdTPeKhLDD1GffplAzVb4klOtQtbGyCUlVmP5zAhMg57sQNWl3ioOq5?=
 =?us-ascii?Q?n3wAieSrR5UeYsx+ps6OKwC4wQfgcKehuymGRcSJ+K/Rkpo3QuzscPmuON5l?=
 =?us-ascii?Q?jB9A/G7/82MemnBsfjVVJyBYSmKWoTtsxYsvg2n/zGzPH5GtHoF8AQG1LNVF?=
 =?us-ascii?Q?12gvNeuBDuW2+KLuKK/B69QTYlv00Ier9uJFxxdtDNSdmur4alUaWcN2JEqZ?=
 =?us-ascii?Q?L4ZQVX6+r58uuQS3kc2ThX5gHP1T2KO/de4jk2qPcrET8D68HwBgbzB7JUr0?=
 =?us-ascii?Q?AGZ0eXoSNfiBra/I00i31Ya5UaAwEB6NUvujKBeV1ewSAtbMVzyxUcHyw0fN?=
 =?us-ascii?Q?4G+kc7mTmOUMD3EnXnr4hGmmlW/y+PkF3/5RgxnVd9plgD+2sTyGJAlnNlt4?=
 =?us-ascii?Q?JkXoLsjh/YHkI3MojW0FrKq9eBI6wsDSdZord2XTAjc5oKqoP708HpVHZWAf?=
 =?us-ascii?Q?EhbqBJzvbZifA+VEYiHWnMhssUVIsSboLODoCRWB/VdvsjFr46sdKIdKf9gG?=
 =?us-ascii?Q?13LWc7S9EKlvREnCrnioYB2JFbBbG49jTtV+vhJYomVoVzn1thQ5dE3RWcDh?=
 =?us-ascii?Q?Xm3CPFQ/ayitWPSsV3P2lag0kNQY1Ae53LTdutM90oNU2dFWeyTLfVjiGWLc?=
 =?us-ascii?Q?ei86C1ankPg6HB10CrRSEcslGFMCeNBH02UmQKvTTZQ8AfeobIll9PZbmPxP?=
 =?us-ascii?Q?C8KxCbUUUgEUQg0dxxG+2z6DVl+kmat0K3ImRbP1PUzQS53hlnRs5A4E6xXs?=
 =?us-ascii?Q?Fm6EFviiMRM8PRaAQ5xMnrRlQVObIN605LzPSz9QiX7xFl7RrlIzV0NLlK/8?=
 =?us-ascii?Q?wsOfSjAAsEVagWRYg7c59hQR3XvRHigKmUm/UF9LkqVfNQsFELBWdXOznd3l?=
 =?us-ascii?Q?KMxdV8cLiGiL9mU3ZIWUlbMAopnh4Q0z2lELjCfpg9fBnyE+ZVRg0S/igVJM?=
 =?us-ascii?Q?6o7+4H2krp2PSWkNgaS/aud8Kx1h9lynqaMsUX3kqvUoq+gAmcFfyXQJqupy?=
 =?us-ascii?Q?w/Wc7elShy4c87e50zLOt8DJO/IdcliXOOv03U5wTKPb7wT05sp2ZeOba5vQ?=
 =?us-ascii?Q?CKLwmgMry1r8B87i8VfIZuiF0oh+naoYAnDy8b230OgZJMirsYndVpTrytVO?=
 =?us-ascii?Q?9z5M9UUEnFb0s8yqReTMipU+UkUfmA5SVpaExx1mjoecSjlgvI6vNOhjdhJW?=
 =?us-ascii?Q?oQ=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?mcCx267RabKKbK8lgE/f8a7pu3VdAtvvR4ABqJTQ5BEmLbLQhoZT9ObG8RbO?=
 =?us-ascii?Q?qZM15AMGQ4tpGWcLywbWN2GfEGkRrRyqoRNBGKV2XjzihE/XkxP0WDA8KPeN?=
 =?us-ascii?Q?5aE0Tt98uuitksCdlMhwLMwDBGCUsjuhFMu8u4Iy54AM01mG1ScCgIlmFRmh?=
 =?us-ascii?Q?ovub+6j1Y4sgWZlPKHgJLHBH++J6v90b2IzuUcLafxXIFLUPmHFlj4hYnLAf?=
 =?us-ascii?Q?bvENry632dUpIuqQHFnHdxi6v3rqSfCcIC5MAwKx3mC3R3w+B8Em3dK6dQre?=
 =?us-ascii?Q?CioXKSaTNzNy6NmUHyNC3Rg5rH+/2ud5Ad0S86ZK1R7X8JHH0RC2P5UlgZKn?=
 =?us-ascii?Q?qE0p1Y1L0tPonGcVZdKNMpwYyoIxjy1pJv8NLLX3R5teg7ZQcdcq4Qu/bVVf?=
 =?us-ascii?Q?nPXk5Vn+c1wZWBF8AjZ5b4p+tzb49EAQB+LGZlDDYaUAabN8RCkjFe2NSW95?=
 =?us-ascii?Q?1JQ6T8Q732LBQat1w8+MJOvk2f+EwdR4IAo9zY4LyXmE7zbDHodt8tnMytXS?=
 =?us-ascii?Q?qqYikb/VqrtKLGlM/atGx+4cbK/rCdzswCNOpaDPlbdNZI9mHZIVSpMEXz92?=
 =?us-ascii?Q?dWyXKXADGUqzpkHTUXFB51+9yQ3W4xdSrIpGiaLXvyrlBjBtvgopXISvXMml?=
 =?us-ascii?Q?tsdiHsdfi5/tUGswQ+kxsNoqIpL6naFElBEBX5ETotRXguTMA5dy/chwvYPJ?=
 =?us-ascii?Q?IlJeaBgedDdSVZUDfFwPI4xHzcR96nYMn4Ww65Vf/P7QlR57AqVfVHe4Bj37?=
 =?us-ascii?Q?r5CzfqSOwrvk86FwdqWT+0RTAhB15i37zHBUINChOnt7S78z54u4Ja1VMRMG?=
 =?us-ascii?Q?GJlL9jHBLfGZS3khQ/rHHi0plyKA8wOkbuQ4P2m+PvVMj8j1mAPQabw7ouzv?=
 =?us-ascii?Q?j4pC6iQdcCL8saxLtm7sbJRr4jUOybiLfHlabTXzGmyI5ZiV5ErsdzrJSaai?=
 =?us-ascii?Q?IbmgyzcMmz/tV9xLTikD6Arhin4/oD0d6Czw7GGk7VoTO/SnYpdC9idH63DV?=
 =?us-ascii?Q?kzFoOQwc9iZBv1Ofw4jJPIqykP4e0492IhV8KqiGhir6bmfHZGK8L4xhLIid?=
 =?us-ascii?Q?JmV0RkvLRxuk5lZTNZGQHW/tbl0a2EuGVhg/27O0Ya4icHV8OupV3POuDz/D?=
 =?us-ascii?Q?H4Z6HWSLilj7SV1cXjFnmYKpujx+sZ8xCWRaNuwHj767zw3WhplMGieOxQiW?=
 =?us-ascii?Q?6r7/aVXyLhR6fbBAVP/I6gV7p7Y7oyb3cT0KvUyP4XlHJabUN8CEX0jIJMx0?=
 =?us-ascii?Q?gCgfeCQddxcmb+3OE/Kx?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24ca5c46-c8af-418f-b6f9-08dbba59814a
X-MS-Exchange-CrossTenant-AuthSource: CO6PR10MB5409.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2023 04:16:18.9970
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0C0z8LgZtAoWFpqDkcY2FowXWKvH6NoU9vGnWrMM//+4CbygbYO0m5ydoABAdeM3KaMg4FZBCsY6F35rI8lo6eq+m1xi4Y/t/RZ4r4YZLh0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6996
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.601,FMLib:17.11.176.26
 definitions=2023-09-21_01,2023-09-20_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0
 malwarescore=0 adultscore=0 phishscore=0 bulkscore=0 mlxscore=0
 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2308100000 definitions=main-2309210035
X-Proofpoint-GUID: 11OBRQ_WE4MruB1ZQe7Atl3DrXsk230M
X-Proofpoint-ORIG-GUID: 11OBRQ_WE4MruB1ZQe7Atl3DrXsk230M
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 21 Sep 2023 10:23:48 -0700 (PDT)


Thomas Gleixner <tglx@linutronix.de> writes:

> On Wed, Sep 20 2023 at 17:57, Ankur Arora wrote:
>> Thomas Gleixner <tglx@linutronix.de> writes:
>>> Find below a PoC which implements that scheme. It's not even close to
>>> correct, but it builds, boots and survives lightweight testing.
>>
>> Whew, that was electric. I had barely managed to sort through some of
>> the config maze.
>> From a quick look this is pretty much how you described it.
>
> Unsurpringly I spent at least 10x the time to describe it than to hack
> it up.
>
> IOW, I had done the analysis before I offered the idea and before I
> changed a single line of code. The tools I used for that are git-grep,
> tags, paper, pencil, accrued knowledge and patience, i.e. nothing even
> close to rocket science.
>
> Converting the analysis into code was mostly a matter of brain dumping
> the analysis and adherence to accrued methodology.
>
> What's electric about that?

Hmm, so I /think/ I was going for something like electric current taking
the optimal path, with a side meaning of electrifying.

Though, I guess electron flow is a quantum mechanical, so that would
really try all possible paths, which means the analogy doesn't quite
fit.

Let me substitute greased lightning for electric :D.

> I might be missing some meaning of 'electric' which is not covered by my
> mostly Webster restricted old-school understanding of the english language :)
>
>>> I did not even try to look into time-slice enforcement, but I really want
>>> to share this for illustration and for others to experiment.
>>>
>>> This keeps all the existing mechanisms in place and introduces a new
>>> config knob in the preemption model Kconfig switch: PREEMPT_AUTO
>>>
>>> If selected it builds a CONFIG_PREEMPT kernel, which disables the
>>> cond_resched() machinery and switches the fair scheduler class to use
>>> the NEED_PREEMPT_LAZY bit by default, i.e. it should be pretty close to
>>> the preempt NONE model except that cond_resched() is a NOOP and I did
>>> not validate the time-slice enforcement. The latter should be a
>>> no-brainer to figure out and fix if required.
>>
>> Yeah, let me try this out.
>
> That's what I hoped for :)

:).

Quick update: it hasn't eaten my hard disk yet. Both the "none" and
"full" variants are stable with kbuild.

Next: time-slice validation, any fixes and then maybe alarm-clock
deployments.

And, then if you are okay with it, I'll cleanup/structure your patches
together with all the other preemption cleanups we discussed into an
RFC series.

(One thing I can't wait to measure is how many cond_resched() calls
and associated dynamic instructions do we not execute now.
Not because I think it really matters for performance -- though it might
on low IPC archs, but just it'll be a relief seeing the cond_resched()
gone for real.)

--
ankur