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 3D11CCD5BBD for ; Tue, 19 Sep 2023 13:43:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAEE16B0522; Tue, 19 Sep 2023 09:43:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C371D6B0524; Tue, 19 Sep 2023 09:43:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFEA36B0525; Tue, 19 Sep 2023 09:43:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9D0076B0522 for ; Tue, 19 Sep 2023 09:43:32 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 504B9140C0A for ; Tue, 19 Sep 2023 13:43:32 +0000 (UTC) X-FDA: 81253464264.05.41C4209 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf03.hostedemail.com (Postfix) with ESMTP id 7713D20022 for ; Tue, 19 Sep 2023 13:43:30 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=INe3beAV; dkim=pass header.d=linutronix.de header.s=2020e header.b=tqREo84z; spf=pass (imf03.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695131010; a=rsa-sha256; cv=none; b=1i8Lsh/I33GNqgt8Gzu0hl2jkl/WcqMd+EaGnEAFuV24Ni+/uY6lEMl6rUI+Ob8XqWbSjW zoIVgopWTHHOFGdXiiGfIax17KKwnI9PtBwLRJWd2ai/bRswsbdptn46A5x5mbzcHUkk99 N+DjDswmycFTPEpQbkd5lVtbfHFKxk4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=INe3beAV; dkim=pass header.d=linutronix.de header.s=2020e header.b=tqREo84z; spf=pass (imf03.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695131010; 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:dkim-signature; bh=F6HJIRD4PyaX4+pUjqGdadn05E3sV+30VO4ObkBi4tA=; b=lhskaWGPBa904ePFXs/lbDBAFi7gVRYo9heXUXWIzEjJqOgfH6dlrFcf/QpyHnFEqfD+Hu CN9+nNkkjbrcb2GOn4Ky7Mme3QYfP7JC+8GaeQ68jLB4dH21QOMwphpm3Zi9sHssxH2FMA +D7Z159Ask+fJjOBELKKEq/Y4VC/a/M= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695131008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=F6HJIRD4PyaX4+pUjqGdadn05E3sV+30VO4ObkBi4tA=; b=INe3beAVUGy7X1rPg0jVCOBApZrBIols9AlzAGXgMjPV257Vi8uogUm7f+1Kqn1dxss5w3 Qd0i8v4W/KraIOm+0T08nhMyYiNAOuSdipyvpsH3wNCmEDgs6EpI6kzYy1p6edIzt5fRsM P3qq2iMbd4rnkAcfTNo2E4Mimdyz7ezivL28bRK930bJKJgeepHh1qRS0BwzW2gGyPjpzO FsKZToH8pgbrfbDvRRO4VZRnQlJziFXI2AOfdGkEzVhRgYrR7LTr5h7nXciBgTG+k58Etx Ndd3xkgzvmITTLqDMaD3fS+b1tdLInm1s1/Jc1ttwJ+JYsXw7NcqZLonBfCbWQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695131008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=F6HJIRD4PyaX4+pUjqGdadn05E3sV+30VO4ObkBi4tA=; b=tqREo84zIB2g7/8J6CTjDIfHTI+ZuUEpff2uM/m8NQcbyKurWmVLCLHVVCMc9TsZfuSA/a /Stk4hnv9k0JS6Bw== To: Ingo Molnar , Linus Torvalds Cc: Peter Zijlstra , Ankur Arora , 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 Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED In-Reply-To: References: <87edj64rj1.fsf@oracle.com> <87zg1u1h5t.fsf@oracle.com> <20230911150410.GC9098@noisy.programming.kicks-ass.net> <87h6o01w1a.fsf@oracle.com> <20230912082606.GB35261@noisy.programming.kicks-ass.net> <87cyyfxd4k.ffs@tglx> Date: Tue, 19 Sep 2023 15:43:27 +0200 Message-ID: <87fs3awa68.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7713D20022 X-Stat-Signature: 35jaforc4ocdor5kkdkbr1pa9wss9o88 X-Rspam-User: X-HE-Tag: 1695131010-229581 X-HE-Meta: U2FsdGVkX1+2IY8XafJ+Di79G8TycvOv9YYYLy4FBogjGkM4mfEmAPvEXPbzFR8/jylQZ9MWr3NWKVr+0cA6Xq6yDIZAL7hlcY4EmqzeD3BX8zc3PZWR7M+wQsxKVsaW6QG8gCqol9+jeT+l2qnufJzYLOVTNtJ9A8bHzpV3unTPH7fEvu+X+V8dL8RbNG/hmF6qDv2k7LN1OCwz4N2QpwcCmTVJ0xFH7NHtHhekTJpweajlrg1B4ft//y5OQU2yaFVKBXAosBVPLAbOp7h6cpx9IbP+Lyruug0wXqQ6Jjd2gKpNFJgbzCfnBTH8yOMaFKDuPfSpGAkZMcV/0oKi1UosCQrcqx0PbzlHdEQKZn3n1qfE7wooE1lVA0p750yiwUeoUnsYNAzvfR8E7mKjWr0pRu51JOiTu3H0hRYt+DvsUbvDbQMzgGOcT/nhbkyW9gM9ScKevqmV37uNrIGLDmJMvpESlbLdUnaoEQlnsVKr4Dhqw7q9T80wLtghk3brxRn5iSGgULRQ19CYpbU1xOV3FmRGyB5poIDOJW5p/6XFg+1z+bphc8nFDsbDaE0pcsywFtbGMy1Z3dZpGs1hL8p3QtlcXOYrFs+hm2OzdLOramfwV2aCebb1R4lualJJyTH2VwzFsAIx+wUnT+gmvtJrPNcsD/2eUEfxxf4mDcZurYyTeDzoq2vBLSb8GhMuFTTcp6/ccdAEYKm4EROoJcNFPDnHAEfIvLsKfe5ukjsU1ms69i8LywJ4LZSvMa7wFTLCwAq+lls48mWCGM2IL+ixCIrHdfk3MKVp19FMpLzoSgyDlmc3/GB+tEts67dbOUyoqf5uTTNRw4Umu/Im7oXEodmKLfgautoV5uUAzOte3vy+LSLlA4Dnled4NmHhKNPg0Afoz3cgY5V/ABc+4ulLno8ZcvySrJ8us11LpBDAJlc5v9TJHok1+BSA3yE661CPu+rLY3PWpBzGi35 Kz//A7X5 3MM5ryen1ZMpqsgMxRQuqO0yhG1Xyf3PGAqFAE+fI6GZ6bnck+HCFnKsjjj/gMdgi5S5icbeh+iJ14yXVXWwfD5YFMLMu+f5z5Uw5Eh/L/PJlL2EfqlCvXIFynk+kDFtTcnPQGwDPwA5hVngZCy+ZceH03A== 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 Tue, Sep 19 2023 at 10:43, Ingo Molnar wrote: > * Ingo Molnar wrote: > Ie. a modern scheduler might have mooted much of this change: > > 4542057e18ca ("mm: avoid 'might_sleep()' in get_mmap_lock_carefully()") > > ... because now we'll only reschedule on timeslice exhaustion, or if a task > comes in with a big deadline deficit. > > And even the deadline-deficit wakeup preemption can be turned off further > with: > > $ echo NO_WAKEUP_PREEMPTION > /debug/sched/features > > And we are considering making that the default behavior for same-prio tasks > - basically turn same-prio SCHED_OTHER tasks into SCHED_BATCH - which > should be quite similar to what NEED_RESCHED_LAZY achieves on -rt. I don't think that you can get rid of NEED_RESCHED_LAZY for !RT because there is a clear advantage of having the return to user preemption point. It spares to have the kernel/user transition just to get the task back via the timeslice interrupt. I experimented with that on RT and the result was definitely worse. We surely can revisit that, but I'd really start with the straight forward mappable LAZY bit approach and if experimentation turns out to provide good enough results by not setting that bit at all, then we still can do so without changing anything except the core scheduler decision logic. It's again a cheap thing due to the way how the return to user TIF handling works: ti_work = read_thread_flags(); if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK)) ti_work = exit_to_user_mode_loop(regs, ti_work); TIF_LAZY_RESCHED is part of EXIT_TO_USER_MODE_WORK, so the non-work case does not become more expensive than today. If any of the bits is set, then the slowpath wont get measurably different performance whether the bit is evaluated or not in exit_to_user_mode_loop(). As we really want TIF_LAZY_RESCHED for RT, we just keep all of this consistent in terms of code and purely a scheduler decision whether it utilizes it or not. As a consequence PREEMPT_RT is not longer special in that regard and the main RT difference becomes the lock substitution and forced interrupt threading. For the magic 'spare me the extra conditional' optimization of exit_to_user_mode_loop() if LAZY can be optimized out for !RT because the scheduler is sooo clever (which I doubt), we can just use the same approach as for other TIF bits and define them to 0 :) So lets start consistent and optimize on top if really required. Thanks, tglx