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 98BEBCD5BBD for ; Tue, 19 Sep 2023 13:25:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 093616B0515; Tue, 19 Sep 2023 09:25:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 043436B0516; Tue, 19 Sep 2023 09:25:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E74596B0517; Tue, 19 Sep 2023 09:25:25 -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 D6FB86B0515 for ; Tue, 19 Sep 2023 09:25:25 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9E268405B7 for ; Tue, 19 Sep 2023 13:25:25 +0000 (UTC) X-FDA: 81253418610.22.9924B5F Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf29.hostedemail.com (Postfix) with ESMTP id CAA99120028 for ; Tue, 19 Sep 2023 13:25:22 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=wzxUu24g; dkim=pass header.d=linutronix.de header.s=2020e header.b=Jc8zgpLP; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf29.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695129923; 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=tBxxm4ru3/VDC+4Jdk17s0visMQQa1pK33oOFPmvJJ4=; b=oS5Ae6K3WLSbjAnEyfFdN6pWaGh4S07MFYUtlUUTb+q5PtX5aC6i44bjVTQeagX3dYCF82 rUUVIbDO7we0hFLm91usN3BciTw/4ONh95yW/vuNu+ClXOk84ABhu2IvmukioTEw0MsOjw NNjrT7/ARn9dlOFfBOLJpMBEkokm69A= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=wzxUu24g; dkim=pass header.d=linutronix.de header.s=2020e header.b=Jc8zgpLP; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf29.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695129923; a=rsa-sha256; cv=none; b=N8F+wZqVh5Fj1PJikflJnVP46nls9G7qvyY431Ua2j78oT4GkHVdKD0NW7EOF/DNwdi8jR E7fT9SESjU8M39xwSvYsmFurC14rfSAjw8uxtRXIdJKjUwOqhooQYzvT7Le3YYcCISZ2Td GEGTAFbT7uecJrQ2ufwYAcduzLqRCAk= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695129920; 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=tBxxm4ru3/VDC+4Jdk17s0visMQQa1pK33oOFPmvJJ4=; b=wzxUu24gogAAAj4c9kQnjebK37Y9s99q7EQDwun6AAnJ1T6yZo4QZ32YKt9XxBlw9Ujh5m UgmeY6XjPOWljLTVz8hascxWgGje/hhJ9pcZw/QfnJo6GaDht7S3kGbk8oLMOyGJWeitwR +eeV33aqvXx/xMj2vJa6inCUcfkDkLURf8Hwh/j6dGWaxfmJqI74cI5IsBpsH9ED0lr9H7 3orm9hhmWotGOhpsSFdfFShrHn3p5oO7/U6A8I7OQ4rL8ksSw17Zb2W5tRrh3yINkaZk/7 MvVeeIagYaHu0S7oRe4aFZkp8Ov5kI+mEo+sgBGEM+Vz+Tfw62RAnFzrlaZpcA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695129920; 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=tBxxm4ru3/VDC+4Jdk17s0visMQQa1pK33oOFPmvJJ4=; b=Jc8zgpLP8A7UB29/YZIxhWwatrV4iyHXB1ZeDZr7CsNwIiuNl3xpqXT0OHBUKb/yBblClE +l9HZQ76ox1GVnDg== 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:25:19 +0200 Message-ID: <87il86wb0g.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Stat-Signature: xd6ehdnx1czzzettazmoqtcbrne4qs7c X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CAA99120028 X-HE-Tag: 1695129922-803051 X-HE-Meta: U2FsdGVkX1/SR+tmZ2ATslYOUmZO6uG/WFx9QZhIea0n1vKQC6egG0VdsVQKRin+98PVyYxxSfkL96mRnx/L/E2caDgM1lWKOA+YhVAOilGK5YQL764+/NWvbH4s50mjNhydhVQ13IjJaWSsuIAmtHV5XP8ac+UuerWxihXorAx9Ax+usPjhdjetASm/soUomRQ4pWro4rsvRKtRq+i1FIlcixD2wwcOFG4vMLQlgM83J6IvP2dW0r8tAOz6VPtNXTdpDiFcOBevo7QuIH/ufeg7czBAetc1kZ4IxibbKhezuuNcqQe97QBD8YFFfaBlfvAyLseVqY0Sp1Yw/aJClbrJe0KP2J0eoEXwUhLP3ZfS168XNU75xbSRavyjnOnzGvFlFUq68OQyPbSUD3URdqv/TDpi3VAnsHdr+wE+F9r6OWPMJOIQKBgsiLEQSCHsYPle/aMuYAt/RKUU8uzSY6FZ3SA57jbByh80Vr5x5fLa6d56v4GWubA6/ZqFPLowjCchIlfGuIrPWDNzEuzTJwucBUX5CPjyUSWUpADhHEiodFtc4uCbB7cCrq1msRBQyikQZ8znaRSEeOcTye/s0yeh1JaaPW/ZeYahBkLTqNROKG1/qwoz6As9GcLtZnBBEEPMNdf2mQ3Dzih5aM7GcsIxReo07E7UL1skQJq5Yzxky+pMfSPe/b5CE6axWbr25wnUj9ZQBnxQhBSMFAORJPM04tAP7JLev2q5app70wxAdkF4fK57pIalaZopcJP350NC4yxVCmf8oGjtAr9lC8iHM9vQ4cYyRX8AdsqKH7sUEz2worOh8TP3nSWPYzaNH/ViFIFk+YGOs/sB7NWXC05QoJCrV/7oaDUyPABDo6gS03Ff90/yRW8XK2Q7bKmakz/ggPRnM2gsz8yBbXNoKvvvf9oYhY9fWOxL9EtMgHDUpThmFl61RGx/tW5ZQl2QVPPKHfNJL/LnalBJiDL SCKok/nS Aoy+1P0mcaDRkRJJVN4OmazikmQRSxNbXsM8SyDmaQbzzOjhnVS5FtZWUqPkxei1RXaHlqB+yWeiKcUIjGeToeL6ZrPPkd9Koo+8ULOsOF/zJOLt43GReBNnZ62VoUdX1Cx1VI9Bo+FRtyke7scLWuE3DqQ== 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: Ingo! On Tue, Sep 19 2023 at 10:03, Ingo Molnar wrote: > * Linus Torvalds wrote: >> Then the question becomes whether we'd want to introduce a *new* concept, >> which is a "if you are going to schedule, do it now rather than later, >> because I'm taking a lock, and while it's a preemptible lock, I'd rather >> not sleep while holding this resource". > > Something close to this concept is naturally available on PREEMPT_RT > kernels, which only use a single central lock primitive (rt_mutex), but it > would have be added explicitly for regular kernels. > > We could do the following intermediate step: > > - Remove all the random cond_resched() points such as might_sleep() > - Turn all explicit cond_resched() points into 'ideal point to reschedule'. > > - Maybe even rename it from cond_resched() to resched_point(), to signal > the somewhat different role. > > While cond_resched() and resched_point() are not 100% matches, they are > close enough, as most existing cond_resched() points were added to places > that cause the least amount of disruption with held resources. > > But I think it would be better to add resched_point() as a new API, and add > it to places where there's a performance benefit. Clean slate, > documentation, and all that. Lets not go there. You just replace one magic mushroom with a different flavour. We want to get rid of them completely. The whole point is to let the scheduler decide and give it enough information to make informed decisions. So with the LAZY scheme in effect, there is no real reason to have these extra points and I rather add task::sleepable_locks_held and do that accounting in the relevant lock/unlock paths. Based on that the scheduler can decide whether it grants a time slice expansion or just says no. That's extremly cheap and well defined. You can document the hell out of resched_point(), but it won't be any different from the existing ones and always subject to personal preference and goals and its going to be sprinkled all over the place just like the existing ones. So where is the gain? Thanks, tglx