From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 489B1272E56 for ; Thu, 9 Apr 2026 18:52:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775760765; cv=none; b=p0m2U+N21//kUA6D8QTiceYLyLLjincQ0y7H/zKg6ogwKoRC4j03dQa9f67+4GLHQas+xVFGNPCOiHy805Toe3zwnpGo/bPIHJjnzex7UPz6aY0nr40GzKXG5upHMUprRgzNGthi+2lSz1h9iURZFAhzShsIBukNKvecvBoqFd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775760765; c=relaxed/simple; bh=X0prDBk7rhe5DGxdjo1gSwu7R0MQFlaV88/mRpEMihQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Yfts2dmZ8YfLH0aHtwLmSG+bQmoGp2MEIrBx3VCg5FHr6z86jJHoqsCictTr8nvR9AM9Tqh+eoCc3FoZbVHxb9MzHZuYUVGp2TDAvS1kgERSTruEIbFeZafAjraMS8+T0no0F8DrPmXy0cKrHsjmWru66sNIh3Dgy6e/P/J2TxQ= 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=V7QBEt0E; arc=none smtp.client-ip=209.85.128.49 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="V7QBEt0E" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4887ca8e529so8329085e9.0 for ; Thu, 09 Apr 2026 11:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775760763; x=1776365563; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=mi8BTj6Hw/bQpfLNH0Q3MEg0hYmiipCC+u6I3n8U+Zs=; b=V7QBEt0EThYCo6h2cMM6oUO1QnetYHoObO2vNHBvS6L84SLFxcQiFL/JMsDHklS/rF yogzqr8e9ScSEqFwhBWkkI6dE90tInV6qgIU404Dz8KzVGqamG45FX6IxxNoCbkGmWoQ ZMdo8Hn1Q5F1jzgXsfUIZ5gEd+tdrQacm5EyPb3ygJqFJ2XlRloDLRTnN3YheaSo63t+ Er23Vaiep8EFHXhrfhOguS9Q0J3NXf0pjAr9sI7SfO5ptxjBjM8vtDaGBNA0DyB8RwT4 0kP8rORPlfUil9kNhG0HgPB4dVWdup01gErOZ5eioH685UHOa9BMn/M9+yFyBYWi88er nmSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775760763; x=1776365563; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mi8BTj6Hw/bQpfLNH0Q3MEg0hYmiipCC+u6I3n8U+Zs=; b=O9fqB0JZORq56E+tZDO8kxmRg+Mz3KmRTo7/QCFly7flPPBJ6Fsh+Aiumh9fRABE9k xyf47xy10sLM+PP0PZ6R4DGU1HAPgra5Cu3FjK1WA2/d7Fr1A7LRjkoPzvapXgfh4gq+ s7taTgDIvMEghrSjVXlw1TWgbMcWtzK3zcIjA+miq/yH37EAYguQHM/GOTmXTMB6Rrj0 WZXrimmbTcgPAwjTKPqnCjlnMlLwtqgn2SnXmHc78rg+11/m+MrkDQ9XGOuT013cHpaX KoePy26oRMpEEreJpBCdYy82+KOgQ2XN81sTUQMGg9ZKRrhX37dH/LyXO3BQc1hJThu9 KZBw== X-Forwarded-Encrypted: i=1; AJvYcCWdmnUL+D3pXT7bYlpPxW66bjE8JQbbwrlA0adq3DzDapLp71Rn/ztWPtN80JMSZMB3QckuxHoIhijCZuo=@vger.kernel.org X-Gm-Message-State: AOJu0YxpUZcgrxKAQrDcZD30dPsJNPmt3w4N1PtdmL0MMF21epYbh5w0 LncTp3McTxoK6flS2o3PIQwK2yq2gPp3Xh+vyWU9OKLbuSq7O29yASCR X-Gm-Gg: AeBDietIMpObRItIK37b8MhzG6KWQs2tAYTp2vYr2Sllr7rnu9kV6N3qrCS1Mnr+2AR SLLSDJvA7JqQFbrCJJI0emNfkkN3erVf9VbozwMlWDIkMgON5UlX/7GA+6p3vPe5u7cfW5FNwFB mseqzMx49Cas8IsVTcUGyazcbEqu2+bPH37vbj40/Ew2cJJul6bRkZVCu0z+BRcQx8aT1R4N0kJ 23pCS9UTynJKZvP10pPZjhjsSQdYJHwPtm3gYfK3V4v8EZWnSxBkEObZAbUBDuIPqhntp4Z/NvJ PuK5HShCz9onYBgr7mpfJPaGoWaD7pdVU0BG3UbJQ9ydSND9xTF0BtE6tqJHOCk8Hx8X6p62AZg Jc1iqx4kzSwJeTAr+GPb4srindgou+IkVC8nI4d2Qu4vbXLH6GfAFKPmtnBt3zR2qGM6IP2H93/ XrC9uNkrT7H2IsepWdQxgT8vkFma2JyryAhlvOtUI3kC4CSh0bMVrwlcStT7P5L7xn X-Received: by 2002:a05:600c:1649:b0:488:9c3b:ff40 with SMTP id 5b1f17b1804b1-488cd68093bmr36636045e9.15.1775760762375; Thu, 09 Apr 2026 11:52:42 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488d5888a97sm12899655e9.2.2026.04.09.11.52.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 11:52:42 -0700 (PDT) Date: Thu, 9 Apr 2026 19:52:41 +0100 From: David Laight To: Michael Byczkowski Cc: Rodolfo Giometti , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/3] pps: pps-gpio: split IRQ handler into hardirq and threaded parts Message-ID: <20260409195241.3fe354a2@pumpkin> In-Reply-To: <44669820-2D7D-44BF-B518-583B672946F4@by-online.de> References: <83318241-44C3-48BE-829D-5C5F82A78A74@by-online.de> <44669820-2D7D-44BF-B518-583B672946F4@by-online.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 9 Apr 2026 17:27:21 +0200 Michael Byczkowski wrote: > On PREEMPT_RT, all IRQ handlers are force-threaded. The current > pps_gpio_irq_handler captures the PPS timestamp via pps_get_ts() > inside the handler, but on RT this runs in thread context =E2=80=94 after > a scheduling delay that adds variable latency (jitter) to the > timestamp. >=20 > Split the handler into a hardirq primary (pps_gpio_irq_hardirq) > that only captures the timestamp, and a threaded handler > (pps_gpio_irq_thread) that processes the event. With > request_threaded_irq(), the primary handler runs in hardirq context > even on PREEMPT_RT, preserving nanosecond timestamp precision. What happens if the threaded irq handler doesn't run until after the next (or more than one) hard irq? Threaded irq really don't work well for timer interrupts at all. They end up like buses - none come for ages and then they all arrive at once. David >=20 > On non-RT kernels, request_threaded_irq with an explicit primary > handler behaves identically to the previous request_irq call.