From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E6C921A447 for ; Sun, 5 Apr 2026 14:44:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775400290; cv=none; b=SJ087Shu0gEIhSiibrqmV+vbylj7TFPBOzbRjFpjCaULKjYb9COD/afUnLS9zsyZuJ4tr71DnQgu4k6GFeullkCDMccancGur6BZs1zoeFoaYk4NKa77eRsaGBFq7ZVjMpYIhp44emwOfS5zpUuAjIcYg8wJtP8NEV7LbhM/XOk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775400290; c=relaxed/simple; bh=xCKQVVfRX9XEe/k2pcWAj5x7mx+vyUPi8yF21tR2HLk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z8DxrA8rxOFHS1+T0ydFN7uDxi4OcNxNAO7T4rG5KNUEBhnYmXVCUtI1agned4uJw2tZ9PXBggOn6teMju6DCLJW0EgCuoQkvaIeJX/ctlqNAoiTpPAezN+8h7NB3bLNQQ8XauP247/H9wGYvp5ECKCSXmmmzpDgnij/z7vXMDQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JXH6FqQe; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JXH6FqQe" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2a8fba3f769so12254875ad.2 for ; Sun, 05 Apr 2026 07:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775400288; x=1776005088; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6lQb3naQqO7tqytz2xjvWcquNkkoKINwEWSDD6ogVfQ=; b=JXH6FqQegRNka2IR8ydLUQlVGN/D59e4PM9S6aRryI1d3pTkde7z52EjAqWI3uR20o JErGFy9vd0Cub8sP+OwUDYUSEBCpicluusLX8Sw/Um14lcxrXzJKR8wzXIOGgm7GODg4 9wjkKS0wvopAwgLkh4WX9p3g5u9w5zke2uj0ASJjeQJRdxTuq+swKDvknje8j8pMFW+U MocRu1cl2WRP+TQZM5kCDYcRoUL/WFSAX/GzqoQfkHjmfeWRcRSyZ8NE+WGSmvSMqp/C uTmqH9NpugLMuHrPcPEhYOeWuAewZox2S2CkFxp5XjdPC02bSCBSrw6pVBkTgnjP2RAG 2omQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775400288; x=1776005088; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6lQb3naQqO7tqytz2xjvWcquNkkoKINwEWSDD6ogVfQ=; b=tO8dc2jl/210UtMt99mYk4DyLKC+FaVHkUJM0cMDu9wOnUQZNiPslWB6tAkgs3PYYp YAGx3Tbcg0+kLdH7zpxbMUZFI6Kn0kXoMTrvd+DEMKKymHGalEpdsiYidPPS6nbIlN82 g3GoWt3OdEsInElrkXgFqSuvy9WdfKjNTVx4E737atWqUl1qj0Jw1eF2YkcRnF9HJrH9 khB7BbO7OFuY5gO6MnyAinSJYajYnPKVL+uhvpw2j4WL8dqSOeuymNgjXae8hU1HiHIM GjL3KRF+yKufTfWBKx9vGMs5QWjRfXSQJLXqzRjPeZ5c80W+3w4yEiBRCkiuy9i0W++E zHEQ== X-Forwarded-Encrypted: i=1; AJvYcCUzQSHAzHSyAq2yMJl/GTMWskKB505z1PdJwflhwGxdFwtzaieiu1Y3s0thVTBWZtLgUSe2gWbnK7D5JaM=@vger.kernel.org X-Gm-Message-State: AOJu0Yxfq1BrxwtY4fUZXZlIkAnwFezToWdbymQIEXL98seyxdIxcdJT qIXyEgVGSzI+04GZtKluK6AfBrl3RDkR7kM3q3LTs+HaOBTMbdSzvu4e X-Gm-Gg: AeBDietl7k2FSom7uSLNeMEvNJgwbM7jFzpplrlOBxxPHB48QHIxVcF+BLEyYjtHkas TnmC+T49N6B3mFrWWIzl67lnlq/AuDpD5MHSe3f8lGBVchmuCqfzbohtjoeAtmT85y7E6I+AGeF sQ5LKPH0Ethwq9Gmxvwp/BaIADKziRBxO+pWBk9/Ywb7TvcQu4mfm0sJgvlz6ncMJgXvRtXOE3s NfvPFy8YFDkKVHF0k0MEbOBVnPBlAFy/MPN5xu3SdhUhtcNbpPwWiY1kI82y/RsHILgSB1jbxI4 3Q/BxlwNFDdalSrixjD6h9I3W8VlCUVZOxx1lKiVRX2zy7/DtfI5Ht3foVXCo2Um0vfnO4vlI37 IYiwsxCqxSuz7SQGUB3F8Ogrola9Igu8WcgnGoFLgk8HQub2sdKoYeyXXAp86DqQkOp43pyMo4o quGYtYaN658AzeaGOjVtwFAjB90XMSAriMwnoQKVltDnYdyEKwwyCEAoPbHflics3bycI= X-Received: by 2002:a17:903:3846:b0:2b2:46b1:182d with SMTP id d9443c01a7336-2b28170fdb7mr106786985ad.8.1775400288553; Sun, 05 Apr 2026 07:44:48 -0700 (PDT) Received: from localhost.localdomain ([2404:7a85:2900:3f0:6514:327:b8bf:af2d]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b2749a3af9sm105765605ad.63.2026.04.05.07.44.45 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 05 Apr 2026 07:44:48 -0700 (PDT) From: Mitsumasa KONDO To: andres@anarazel.de Cc: abuehaze@amazon.de, alisaidi@amazon.com, bigeasy@linutronix.de, blakgeof@amazon.com, dipietro.salvatore@gmail.com, dipiets@amazon.it, linux-kernel@vger.kernel.org, mark.rutland@arm.com, peterz@infradead.org, ritesh.list@gmail.com, tglx@kernel.org, vschneid@redhat.com, kondo.mitsumasa@gmail.com Subject: Re: [PATCH 0/1] sched: Restore PREEMPT_NONE as default Date: Sun, 5 Apr 2026 23:44:25 +0900 Message-ID: <20260405144425.36044-1-kondo.mitsumasa@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20260403191942.21410-1-dipiets@amazon.it> References: <20260403191942.21410-1-dipiets@amazon.it> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit I believe the root cause is the inadequacy of PostgreSQL's arm64 spin_delay() implementation, which PREEMPT_LAZY merely exposed. PostgreSQL's SPIN_DELAY() uses dramatically different instructions per architecture (src/include/storage/s_lock.h): x86_64: rep; nop (PAUSE, ~140 cycles) arm64: isb (pipeline flush, ~10-20 cycles) Under PREEMPT_NONE, lock holders are rarely preempted, so spin duration is short and ISB's lightweight delay is sufficient. Under PREEMPT_LAZY, lock holder preemption becomes more frequent. When this occurs, waiters enter a sustained spin loop. On arm64, ISB provides negligible delay, so the loop runs at near-full speed, hammering the lock cacheline via TAS_SPIN's *(lock) load on every iteration. This generates massive cache coherency traffic that in turn slows the lock holder's execution after rescheduling, creating a feedback loop that escalates on high-core-count systems. On x86_64, PAUSE throttles this loop sufficiently to prevent the feedback loop, which explains why this is not reproducible there. Patching PostgreSQL's arm64 spin_delay() to use WFE instead of ISB should significantly reduce the regression without kernel changes. That said, this change is likely to cause similar breakage in other user-space applications beyond PostgreSQL that rely on lightweight spin loops on arm64. So I agree that the patch to retain PREEMPT_NONE is the right approach. At the same time, this is also something that distributions can resolve by patching their default kernel configuration. Regards, -- Mitsumasa Kondo NTT Software Innovation Center