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 863CCCD5BCE for ; Tue, 19 Sep 2023 14:51:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF0776B00A1; Tue, 19 Sep 2023 10:51:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA1A16B00A2; Tue, 19 Sep 2023 10:51:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C68416B00A3; Tue, 19 Sep 2023 10:51:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B4DD96B00A1 for ; Tue, 19 Sep 2023 10:51:30 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 836754055E for ; Tue, 19 Sep 2023 14:51:30 +0000 (UTC) X-FDA: 81253635540.18.ECE355E Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf23.hostedemail.com (Postfix) with ESMTP id 522ED140029 for ; Tue, 19 Sep 2023 14:51:27 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none ("invalid DKIM record") header.d=zytor.com header.s=2023091101 header.b=rKxd+En5; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf23.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695135088; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tUr/tHfO1etLyJ5iEsuuEqfdyv68/fcilJS639sYECk=; b=yr+mx7mZw3dafuSaL19NdQmXJgYKGYEiMU/DG3+vcxtkGDfFqx64tGsb28n0QwzWyrHyNd /7BC1OcPSJA8bDO9fkYJ4IrLW5iesJieuvOacWT0lP7bGon74V18bfgCVWBeXpvwWjEEtT 9huoZJtw/qa4QDrXeMOZ7dfWmJSjHL0= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none ("invalid DKIM record") header.d=zytor.com header.s=2023091101 header.b=rKxd+En5; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf23.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695135088; a=rsa-sha256; cv=none; b=r2XdE9K1X4ikkIDQ2vqtkUOHe9YPYb51I37OholN4JmRJHNJ4hB+fgi9LYo96VhnYUrAgK QLYOfpa3VNYOhhawRM6E95xUJvaSBO586bx+YR6NZFxmUlb0HlwD5bHWt0pFmlKP1V3cd6 hDapxqI/HEiK8OlHZjpqZyr5mrkuY1E= Received: from [127.0.0.1] ([98.35.210.218]) (authenticated bits=0) by mail.zytor.com (8.17.1/8.17.1) with ESMTPSA id 38JEoefQ2134063 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 19 Sep 2023 07:50:41 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 38JEoefQ2134063 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2023091101; t=1695135044; bh=tUr/tHfO1etLyJ5iEsuuEqfdyv68/fcilJS639sYECk=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=rKxd+En5VITJVOEGiLmUKlIHqjSXGvGPVilskDP5cDHYQFDKWK93NnuXqpVPm85sg IQ8mukavFvwyuQ2+LZQx/SFeLAJwt3NRGCnufaQHbyTI8yWPctJU8mvsKC8ydIURew TWPjynPQFVYSogaCk173v4hcW64i46jcQU9Kvle5dlPXtXvcQsapqcrc0+JX4lPkGr sf4WDdKOaq1+eQt1DQ0rhsH9vVqYCi8L00mlI3ZyOafcEgEQnuvBKUCD1TlG5Gwolf v/ICNSdydZcPDXpEjwZCuJJ1aG9hOBj/BpI/RLMLoqn1ibICPlO3SW2Zd9eA3bsF4x ffTTSTGuqyWmA== Date: Tue, 19 Sep 2023 07:50:36 -0700 From: "H. Peter Anvin" To: Thomas Gleixner , John Paul Adrian Glaubitz , Peter Zijlstra CC: Matthew Wilcox , Linus Torvalds , 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, 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@vger.kernel.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 User-Agent: K-9 Mail for Android In-Reply-To: <877comw8m7.ffs@tglx> References: <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> <87led2wdj0.ffs@tglx> <0e69f7df80dc5878071deb0d80938138d19de1d1.camel@physik.fu-berlin.de> <20230919134218.GA39281@noisy.programming.kicks-ass.net> <877comw8m7.ffs@tglx> Message-ID: <7EB81196-3A32-4638-A076-0C0CFF722996@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 522ED140029 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: w9n4gcofc4bi8uwg8ygyo4nfkqehup3d X-HE-Tag: 1695135087-800402 X-HE-Meta: U2FsdGVkX1+F7IUAM9ORY0YXI3UyRCDE+ZNVoayv0STbRmNLSllHOCYIsbJ0moKyxt/6Y1oOMLJe22iuWpGBgdSQanuzUZf5hCeTyqFpY1Rm/EMKmTzkEVqHUlYsWEqx/4na2ovWLniJTf1QwZ0GuyeVkj6mu3ByLGVhkIAiYWJqNg2cizpMC9iom5pvAj76nMsMSUXU5YoN7pGQABKzAO0y64F+thkVEX1tEMOfQ2IghQe/xIlyGux/1z1F8knq2dCVMnJ5nvEFfCSIdRGx2ELY7yWg27G23iW7n07hrZNaIja+0Jg/DfV6/9koBPPPR75ix4jICPq6JfjrLxsCZT3/ZykJBaBhj6c5WQqzegaub9Igzcf6ZCH58B6lw5BftR3uCclu/BHsho1wWRCsSp3Q+MfFl9d7hRsp7PqaiMAQhk15cBHvsWJoBlb6HFYNvExtiumvl4VTpVK9gzbucPUNAbGqCmiEbhte386TDjZ8fl0cGBmONG4RBs99VtWXKg5oIo5Cmgycgp8uc8x7ailH5jBJJaMqO4wef8v5kWhtFD7PwPDTlxcTHKqoRNoBGeTsPJsvcRij9Z0cnsBC1PvR/3QwBSsK52xnfMw19gPv5X4tMKvSZ2Gi/BLvmBZcZ3kIB2hlnSujICTUEwGbnwaM0igO+BkJ5rZ46LERT+o8givpAP5KvIxwc3UW/pvvETwk5rnxPlH/uXTm74un5HE3u5LKjgXmPr7+QWSfWXDlO8/rEkHishbkTVcpJAS0wqLkbvs1E8qi91EWmruGTombZcxa4RXL4q7hurtXJuBvN0Dm1yIv+m6Qr1umYFsDASglbbcxRawXoZLrbNusJ5CX/NaeHQXa7uQ5Y5Qd2moVwmBUW+y44gTG0FypUYTbvocF75pcIPuR67QofbyF2yRKnCSvJxwfFvIsCfWu/ASarWoN4i4cdwIeH6UEytoYyIjsBaEwmJ0toUy6hCM sYRXLWyZ SuifHmqyGWbKYFa8JeUr1YY2WEBjuKbJ2B2TPPpZWBTWzVxMDjTxqRnqWIp6K/FnkzXb5DBpfB3ztfalH7OEz9v5JmIHEDqY9ufc/u0H+DsZupiDFGOzPsPbK9g/e+GHFAMHy4g5Rp55D+aeqFVvzThekXBeVv6G6VmvYTPPgVGG4CoVD9J0FsoQ4OrsThVqM3xr/ 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 September 19, 2023 7:17:04 AM PDT, Thomas Gleixner wrote: >On Tue, Sep 19 2023 at 15:48, John Paul Adrian Glaubitz wrote: >> On Tue, 2023-09-19 at 15:42 +0200, Peter Zijlstra wrote: >>> > The agreement to kill off ia64 wasn't an invitation to kill off othe= r stuff >>> > that people are still working on! Can we please not do this? >>>=20 >>> If you're working on one of them, then surely it's a simple matter of >>> working on adding CONFIG_PREEMPT support :-) >> >> As Geert poined out, I'm not seeing anything particular problematic wit= h the >> architectures lacking CONFIG_PREEMPT at the moment=2E This seems to be = more >> something about organizing KConfig files=2E >> >> I find it a bit unfair that maintainers of architectures that have huge= companies >> behind them use their manpower to urge less popular architectures for r= emoval just >> because they don't have 150 people working on the port so they can keep= up with >> design changes quickly=2E > >I don't urge for removal=2E I just noticed that these four architectures >lack PREEMPT support=2E The only thing which is missing is the actual >preemption point in the return to kernel code path=2E > >But otherwise it should just work, which I obviously can't confirm :) > >Even without that preemption point it should build and boot=2E There migh= t >be some minor latency issues when that preemption point is not there, >but adding it is not rocket science either=2E It's probably about 10 line= s >of ASM code, if at all=2E > >Though not adding that might cause a blocking issue for the rework of >the whole preemption logic in order to remove the sprinkled around >cond_resched() muck or force us to maintain some nasty workaround just >for the benefit of a few stranglers=2E > >So I can make the same argument the other way around, that it's >unjustified that some architectures which are just supported for >nostalgia throw roadblocks into kernel developemnt=2E > >If my ALPHA foo wouldn't be very close to zero, I'd write that ASM hack >myself, but that's going to cost more of my and your time than it's >worth the trouble, > >Hmm=2E I could delegate that to Linus, he might still remember :) > >Thanks, > > tglx Does *anyone* actually run Alpha at this point?