From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpcmd11117.aruba.it (smtpcmd11117.aruba.it [62.149.156.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 069D81514E4 for ; Mon, 6 Apr 2026 15:31:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.149.156.117 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775489505; cv=none; b=eiHcP6G1biGzkg2gqjpieGVZ6cCHj7XxWo0XUQXvTc5xPBA+3i15hUD4/Em7Y0ao7D35HGHpA3gakYVsir06oZ3mT6x1J5J1tzDDw9GzG7stRmbZuimiqN2N/2hSFjHIm9ufMDF0g6o15qY1sBLtPfMqvWQlQs9mPnw+5RmKCNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775489505; c=relaxed/simple; bh=Kj42AaGXZHmtzvSw6k2oezmeLs14ymFhR7Iwx4c/eMU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dPXPW008k50QcoANe4dwvYKgAcDXcH6QmZddYGs1wcp5lJrVQ1XcFpUzz4Z7+ThAWmQ+63tXFZdmmYlxgsnF2Mrci2MR1U/iKU+IXxus2Wvd+c906Es1a3CuZNXqdVO9SszjnhePs5KjT6etfndDcSMTA2JukFp+ZT0TOZ3JdTA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com; spf=pass smtp.mailfrom=enneenne.com; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b=kbbo4Nqb; arc=none smtp.client-ip=62.149.156.117 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=enneenne.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b="kbbo4Nqb" Received: from [192.168.1.58] ([79.0.204.227]) by Aruba SMTP with ESMTPSA id 9lsMwqj8Ffibd9lsMwRuf3; Mon, 06 Apr 2026 17:28:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1775489311; bh=Kj42AaGXZHmtzvSw6k2oezmeLs14ymFhR7Iwx4c/eMU=; h=Date:MIME-Version:Subject:To:From:Content-Type; b=kbbo4Nqbl8jIXR37xOFATZhc+20ByKF7GRruxz0oy1qeZ8rJOfhoJ+xLeNYfVuJYY wFJi+w49MSbmZsVFnBOAo8wx8jIXkdfjgJGj6oXkD5pNOeKzxHGjTjB504IbAjDATJ 6eAI4WFefZzocv/vft7ddyPhMnV1f0nhVg5vMS2z0BXinOcI2qw2J6AzEtc8kdJ0SW Smb4Y/twfKveHkmwlMFdyH9zm7i+838HHR1G1abtPfKDiz6bievq9geFHPka/q7XMb Pf1VZO9uNCe4vtIPCamRO86KUWtUmOkl/T3p0fLHYb64qkoE6GOep6R0WmRfidBI/S fWKTrOom/shAg== Message-ID: <09e5edda-0185-4334-98e0-172d9fc004c5@enneenne.com> Date: Mon, 6 Apr 2026 17:28:30 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] pps: improve PREEMPT_RT performance Content-Language: en-US To: Michael Byczkowski Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org References: <0D0865AB-8578-4D25-BE04-0933326E1F17@by-online.de> From: Rodolfo Giometti In-Reply-To: <0D0865AB-8578-4D25-BE04-0933326E1F17@by-online.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfA+U3EakDcnb0K5fYbTWlgcU0A0+K75525SpoqojFvuECklRNoEWc6gCKH4rDcsjRepIAG290MydEs5W/YMWGU6Cg2mdIGsyQdZfXLQf3jBRm/hFXWIl n+Yk55e3kGeibBx5fBBVPAJzSywHWdk2+tbS9XYAzDAp4v4Qr2JKYhbRbOVWxmBE8XzQt0WXYJs+2eobrazsb08JrpGin50ZZhMjH61Rfc9uKiAO6sYuA9bB TrXL4ewg/76XLzBJ79/ED9urviPIgJCeXl6VkKURmFc= On 4/6/26 14:11, Michael Byczkowski wrote: > Dear Rodolfo, > > Andrew Morton pointed me your way as PPS maintainer. I'm running a > precision NTP time server on a Raspberry Pi 5 with a PREEMPT_RT kernel > and a u-blox ZED-F9P GPS receiver on a Rapsberry Pi HAT providing PPS via GPIO. > > I found three areas in the PPS subsystem that cause unnecessary jitter > under PREEMPT_RT, while being fully backward-compatible with non-RT > kernels: > > 1. pps-gpio: The IRQ handler is force-threaded on PREEMPT_RT, so the > PPS timestamp is captured after scheduling delay rather than at > interrupt entry. Fix: split into a hardirq primary handler (captures > timestamp only) and a threaded handler (processes the event). > On non-RT kernels, request_threaded_irq with an explicit primary > handler behaves identically to the current code. > > 2. pps_device.lock: spinlock_t becomes a sleeping mutex on PREEMPT_RT, > allowing pps_event() to be preempted mid-update. Fix: convert to > raw_spinlock_t, which compiles to identical code on non-RT. > > 3. pps_kc_hardpps_lock: Same issue as (2), in the kernel consumer path > that calls hardpps(). Fix: convert to DEFINE_RAW_SPINLOCK. > > All three patches are tested on a Raspberry Pi 5 running a 7.0.0-rc6 > PREEMPT_RT kernel with a PPS-disciplined NTP server. They apply cleanly > against mainline. On non-RT kernels, raw_spinlock_t compiles identically > to spinlock_t, and request_threaded_irq with a primary handler works > the same as request_irq — so there is zero behavioral change for > non-RT users. > > The patches are available as individual commits at: > https://github.com/by/linux-PPS > > [PATCH 1/3] pps: pps-gpio: split handler into hardirq timestamp and threaded processing > https://github.com/by/linux-PPS/commit/e811a4e6f63f39a782db2a2fe1588419de96275b The patch looks good to me; please add your info 1 above within the patch description for better documentation and add my "Acked-by: Rodolfo Giometti " line in the new patch. > [PATCH 2/3] pps: convert pps_device lock to raw_spinlock for PREEMPT_RT > (covers include/linux/pps_kernel.h, drivers/pps/kapi.c, drivers/pps/pps.c) > https://github.com/by/linux-PPS/commit/918e6f9c87adc552bda3b9b5847eb535f943c68e > https://github.com/by/linux-PPS/commit/d1eb9d80768f6648ff4638b5f83028344f0860e9 > https://github.com/by/linux-PPS/commit/1f149bf2c449a36730adb341fdf626ed07953f5f Please merge these patches and add my "Acked-by:" tag in the resulting patch. > [PATCH 3/3] pps: convert pps_kc_hardpps_lock to raw_spinlock for PREEMPT_RT > https://github.com/by/linux-PPS/commit/a37a12ed96c8d5d0d73ac9e8f43cf0118cc72c1c Add my "Acked-by:" tag. After that, resend the patchset as suggested by Andrew. Also, consider adding a "Tested-by" entry for the whole patchset. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming