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 D24A1CE79AD for ; Wed, 20 Sep 2023 07:29:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 599C26B0125; Wed, 20 Sep 2023 03:29:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 548F36B0126; Wed, 20 Sep 2023 03:29:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 410BB6B0127; Wed, 20 Sep 2023 03:29:29 -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 31D936B0125 for ; Wed, 20 Sep 2023 03:29:29 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 09B8CB3EC0 for ; Wed, 20 Sep 2023 07:29:29 +0000 (UTC) X-FDA: 81256150458.04.05C4511 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf08.hostedemail.com (Postfix) with ESMTP id 1FD25160007 for ; Wed, 20 Sep 2023 07:29:26 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fPAAWyXT; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf08.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.42 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=1695194967; 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=b9FUmFWGdaoCCAX+yBYd9oidTjhPdRU5Hczc1k2R6GM=; b=IQU7QkbjzxLQbzpsYNi/QrplLV0px9TFaurPCjxD05broqC+x4Xgie96cwznBOG9BriC7J 0Ey3wIA1SFbnPpzsy3+rjcCTWX1J2Q0HVB2ND0qGyYEoZbHo8qqbRSbJRJ4gx/YaRtyDNZ lg+8z6+1hRT5ccC4EtrL2zc5KCN5zCQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fPAAWyXT; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf08.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695194967; a=rsa-sha256; cv=none; b=w/njYMmhEauSNNiMxXEwUAdYG90ACeb2hrQvm3zFkxL2DNbhYwUy6VT5lfe6q8OTTVwxgj FhAHfYFRKe1QW43zfeDu4V6xRLqvTKIGYsWi8hNjsNy6dktEUnL9bTMUjQ5u3xvistmR9k Lp8zf0g7VmE092WXaJaaNosyZjNgzUw= Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-403004a96a4so71908215e9.3 for ; Wed, 20 Sep 2023 00:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695194965; x=1695799765; 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=b9FUmFWGdaoCCAX+yBYd9oidTjhPdRU5Hczc1k2R6GM=; b=fPAAWyXT3RSmeFeICZC9/YqvKxg6I0Qvol7c3L94CCm7PRP0kKAXLXpPvlpyZY7pbt fE7u0fCrNcS+QQ4hZLn7ula1wv32EbUkq7n/x+0K7x1Wv1w03nqoJmLaa7X5Ce9ML/54 3ENDWhMGmjAKDeytGGS7Qc0gEKxkDxQUGc2Tdh3Hvm70aTLaiCb1hS2YxJDPqSPubytk kereRYh0+gKxzGzzIDDf7lbsp/7Je2TmqygvlEMCG6O3aE3HpvP/BH08zgV4HXWYHAmB XN9uaICfhoKMZWA/Ys/VZRU1WbmUF5G8qlWqhNm4ueBV3tbi50WiZUlUJoTL4Yi84Y72 Ihbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695194965; x=1695799765; 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=b9FUmFWGdaoCCAX+yBYd9oidTjhPdRU5Hczc1k2R6GM=; b=MRdzV+cGVDU7ed51qH/px9G9Nxfmg/NbxX2l2VZlLc79GjLrRvGCQP53XbUE6MUr8k YCc29RiiJ96zPYBjnP2GPjSYu2t+Itq4IPgsJF+ZcaB5jFWk1lNMbV11e3ojREw1Wx0T Uur0QSxJjdIz0OR5mgoJZUUVLg2Kb3Oj8JP73RuWwkElsXOGjEHBgbwvKaXPXbjjwrLe 4S9LWKEFBHXGLuaprCsaPR2kVcXyyH8R44UVIYP2jQPEjpFRB7qAppRuq3l+5gyoiT3i OhCi2BNE79ZCSjVjH+a+O7AbgHOzzbfUf/a+K+SWB+kFtRrBaI9hzFquKoZW6QSeSFtS KvbA== X-Gm-Message-State: AOJu0YzTqUDVWNlNrJ77jZy4A7x7dxlPvuR4OEKAZYNP8yVgNVRKZOBd TL5DUg+0lHQ82HtsdK3jNi8= X-Google-Smtp-Source: AGHT+IEpVnT/Cd2oEohbdKSMFoVqTb9dtDqJrcJ42h6au+YxgKEXvw3MWUudbGLbWXtUB4DWJ+z6pA== X-Received: by 2002:a05:600c:152:b0:404:2dbb:8943 with SMTP id w18-20020a05600c015200b004042dbb8943mr1805727wmm.2.1695194965229; Wed, 20 Sep 2023 00:29:25 -0700 (PDT) Received: from gmail.com (1F2EF265.nat.pool.telekom.hu. [31.46.242.101]) by smtp.gmail.com with ESMTPSA id t19-20020a7bc3d3000000b003fefca26c72sm1136535wmj.23.2023.09.20.00.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 00:29:24 -0700 (PDT) Date: Wed, 20 Sep 2023 09:29:21 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Linus Torvalds , John Paul Adrian Glaubitz , Peter Zijlstra , Matthew Wilcox , 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, 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, Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, Richard Weinberger , Anton Ivanov , Johannes Berg , linux-um@lists.infradead.org, Brian Cain , linux-hexagon@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , linux-alpha@vger.kernel.org Subject: Re: Arches that don't support PREEMPT Message-ID: References: <20230912082606.GB35261@noisy.programming.kicks-ass.net> <87cyyfxd4k.ffs@tglx> <87led2wdj0.ffs@tglx> <0e69f7df80dc5878071deb0d80938138d19de1d1.camel@physik.fu-berlin.de> <20230919134218.GA39281@noisy.programming.kicks-ass.net> <87pm2eui95.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pm2eui95.ffs@tglx> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1FD25160007 X-Stat-Signature: 789tcqcwmaswagnjhm8k47yohne4qhut X-HE-Tag: 1695194966-959354 X-HE-Meta: U2FsdGVkX1+ZdJIXdQLZWYDF0ECXUAEpJR9POIRluYvUJwRpe+01rrUQ1LjXLQD/PNMH6llSNkuFSzV40pf9Yd04vqj20VWu7F50EKvB3FSEolR0MMO+cxJ2KR1M/kU+shVzc+024B74FyejzKdYFVikuwix/ryX3vOX5Nihz9WDOJFni0rwi6DJqkxGsewy0x7G48WTMotFiC7l2BFoYFixJaIdN1ph6R0nIHrdTVmWvxZi4VTt8xkT2c8rgf+5QY7dIoCWz670xJmMetFUfZFwOLci7Ol5iRNY5zfbZBSKK8p/MVbfb2OhHZlQSz7KlSmbPtozkTgsjDp93IQ2KOgiTQKP3G64ezqEYqdedBopueSfmtWI49jcIGtSWrRbpXfoO2HDKJ5khB29bRiJZQ2YeX34zuf49R12I5Db4dL5sKMtRkE/+7BqJ0J2xiGBmx3asHAEUOIGJIn2NgEmlw94BpoeOE/0OdwsrGha06MFMCBWJnQsX3berrMqdixn7v1W/bTT4T9AgdfIdGUtgdAW+iUFes/b2UVq+EivnG0uzcQ1/4FxSPLVyJWKaFrhcGgA/lvNrqLwyK7TbbN7KBLhLx2GQcXulKCJqc3F3TMgWE+WmN8rwZDPbI39XsyEvU0gysRxGVvryYDXnq3QDh6wWiP2nTp04evhwZTJK7pBvbZiwon13EaEs2T+AXm77+IzNAlccerYn0vZ7CAupj3QHVtslglo+vcazwf4WCJBtrKwd9ZGVD4SCA+/J04B3G7FFWwBYZ+UEPvu1jeOqcOwSS80lrhgJ69fvbsXEqxxzP/lXWkWZMtRxpQZxU3yy9UOjyyIiHaTsnNixWVaYgvXvxIYEkVIdwycWbPy+F8RHsOOsbBQdZni4ufXGEhr/Nc/J6eqNT0789F4EI/aAZnBWGK6RErbiD0esXiRwaaCOplvcQBW1iNswMguoqGSuINC2dCdOHWF8WTYnMl 0WOygYKf YZ0MY8IPnl7LW3UjZXrOmUI0X4se54fBYopAqRfYL2tMviqEnm3fFFicy5ag+SEf2ileQrVi7cNi09z3omfHDGD6oBlTuOO6nYQP0qC6X7mDt9SlAsKVt0g+T60FjcYaAJiHgvEF9Oo3r9+N/Ap0+td7JMDi+PQ3Bj1agrC50fAUUKqVdL8JJ8ZfKpxoj+K0m8Ik2qhVOnY9oEiID4P8whumqhf25WPmYV+C3oP9rj+4qqEoh3EvDHajVjkKN5864RHDykMBFpxPlPQiE27QLf2vJnzwIMJdXcNrXstRO01QP6sece474vkiOqZdXVUcCvgzpZxhzXGpzKm0Yvpd9h9gDOMoSmfx7sLsl4Oc67M+NDtTammQVR5V3v20wQhtahb8/AdLx712DPEk7WSrXZVnWbn2n/Zp0qwKsuHZV7D1jrPZxskiACrsbpxg78PyG4RZgRYf/6LoOvM0lD/KnpJRBSz09rt6rnn/Gbx9vkycxOkVUMVt0iiQnzBBBMs9wc9WLt6h/q4ZuYkI= 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 Tue, Sep 19 2023 at 10:25, Linus Torvalds wrote: > > On Tue, 19 Sept 2023 at 06:48, John Paul Adrian Glaubitz > > wrote: > >> > >> As Geert poined out, I'm not seeing anything particular problematic with the > >> architectures lacking CONFIG_PREEMPT at the moment. This seems to be more > >> something about organizing KConfig files. > > > > It can definitely be problematic. > > > > Not the Kconfig file part, and not the preempt count part itself. > > > > But the fact that it has never been used and tested means that there > > might be tons of "this architecture code knows it's not preemptible, > > because this architecture doesn't support preemption". > > > > So you may have basic architecture code that simply doesn't have the > > "preempt_disable()/enable()" pairs that it needs. > > > > PeterZ mentioned the generic entry code, which does this for the entry > > path. But it actually goes much deeper: just do a > > > > git grep preempt_disable arch/x86/kernel > > > > and then do the same for some other architectures. > > > > Looking at alpha, for example, there *are* hits for it, so at least > > some of the code there clearly *tries* to do it. But does it cover all > > the required parts? If it's never been tested, I'd be surprised if > > it's all just ready to go. > > > > I do think we'd need to basically continue to support ARCH_NO_PREEMPT > > - and such architectures migth end up with the worst-cast latencies of > > only scheduling at return to user space. > > The only thing these architectures should gain is the preempt counter > itself, [...] And if any of these machines are still used, there's the small benefit of preempt_count increasing debuggability of scheduling in supposedly preempt-off sections that were ignored silently previously, as most of these architectures do not even enable CONFIG_DEBUG_ATOMIC_SLEEP=y in their defconfigs: $ for ARCH in alpha hexagon m68k um; do git grep DEBUG_ATOMIC_SLEEP arch/$ARCH; done $ Plus the efficiency of CONFIG_DEBUG_ATOMIC_SLEEP=y is much reduced on non-PREEMPT kernels to begin with: it will basically only detect scheduling in hardirqs-off critical sections. So IMHO there's a distinct debuggability & robustness plus in enabling the preemption count on all architectures, even if they don't or cannot use the rescheduling points. > [...] but yes the extra preemption points are not mandatory to have, i.e. > we simply do not enable them for the nostalgia club. > > The removal of cond_resched() might cause latencies, but then I doubt > that these museus pieces are used for real work :) I'm not sure we should initially remove *explicit* legacy cond_resched() points, except from high-freq paths where they hurt - and of course remove them from might_sleep(). Thanks, Ingo