From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f52.google.com (mail-dl1-f52.google.com [74.125.82.52]) (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 B3BCD38B7C9 for ; Mon, 6 Apr 2026 17:25:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775496303; cv=none; b=G8DXGcPQBpbw+V58Ab4WTSl0pMxQb1/le4IH55sV4EGOG0z9AodCpTFxM33FmhVKGpo3SfYGPtBaQ/lB9UPs2MmB/QtU2HeT1O/uilD277uYXc9fTPdOx50V2TAXsYVwqDyCHrvpqVXEnzLQEePO16jUAO2cOlNB9ZXi2MAyYEA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775496303; c=relaxed/simple; bh=iMJqgrSneeSxiWIfdXKo5CJ2YuKNLi0hawcHrYaYvVI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tAWDJuTEoiY4Gk9tcP0XHikj8cMWeJq2unRmX+aj7MDRZ3h6hIjvZgH2FE6dxhTEXLOKt4wt5dQY9VVBMWufWlLO5fONYzjRrJHI18CmI23WRcer7CzMLue59GiWQaefzKKw8K+wPvfPG0K58ZXZjWpdub6xvpl0DkPnfdbh/+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org; spf=pass smtp.mailfrom=wbinvd.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b=cQZ30USc; arc=none smtp.client-ip=74.125.82.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b="cQZ30USc" Received: by mail-dl1-f52.google.com with SMTP id a92af1059eb24-12a74039dc6so2961647c88.0 for ; Mon, 06 Apr 2026 10:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1775496301; x=1776101101; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=mqS1BSPWtPhEBJHmiZbtN4OkNnko3UvLGgiLXeZt9/8=; b=cQZ30UScnCCD0c8Wk8YuHlrlp9RjmVFfUyjpJTZjSjJqBukY2OyeHEcoAxK9sXzmEC NEp71rKADvLh+A1mz4K0ieV6Hga2CbBZWkAnkdFnr9Px9bMQaXF7SR05uHDAkVc5FMmp VSOIzRBkCw5tdmIYWwyO9EgRdGINE1ZjSxozZSFJvhcFYyOlQq5rahm2QKb8WEZlOCDO zoVtPJlJyZPei2vaHCSRv55KqDucgPJ5AW5Bhd59tHlUB3FVGmUN1YMHT8CTaJi5NzYq YSEXzhhPgD8XSFb4hTb2dTwEiMeHFWrRlDbiwbUIxJcLNbSSHUf0ClVVIr4CJc6HuMcb RwcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775496301; x=1776101101; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mqS1BSPWtPhEBJHmiZbtN4OkNnko3UvLGgiLXeZt9/8=; b=mcMAk2DevsFx+vFJ7g+SpNUH0uzazXq+ERx8wxR/z0vjx7l9esmwD7tcEGx6TuwyUW YYOnhWWRFLcZ+ErE2KZY6oLRwl29SwnKBJrY2LPgxqK2S6CmZ3csw7VpPg68JQvPeepj fal766gU88CRVH+gUeWBzn/shFhmgFoSUISjUIJLzFz9p1AqEI3RzEqIE+WjrDdxGzL0 FdISO0ype7FFja3OM8Bk83frumKLqWJK38YTozDLgtzzNXzkGgQ8dR8VMbRqqiIuIxjb eJQ3RFw9cxbPFtkUdWzIUgZ5haAUdb1rsbsbMpP35JX62vl0+0aQhLwfXZ3qiYv1LOie mPbQ== X-Forwarded-Encrypted: i=1; AJvYcCWoxoABm/ymCyRBxPbwT1JDB7iZUKKg/GwVsbncQtY+CYvFoW5r0kqagg10GJR0Oj4XD7wboiEhgooWlPU=@vger.kernel.org X-Gm-Message-State: AOJu0YxlPfaEz7oMYqMJukm2UzZSao+Th/jSmsehL4wLNE7qq1JjD/eT BkXsV6j8LFytrlgTt81N4kwUwJJ+ffCJhT0ghGCwCMN5mJcYcWsOKLvx75gMECpnPOHXMWQRaAU YFNZ6 X-Gm-Gg: AeBDiescHKgLhKt+sjhTgFJh0XunWT7L+30LfR1Y/BhtAXDtXzErcOI3tkrRjjMeIq1 M0zr7PcCwG5UiPZn1iu71+qXRKocr8kZHDJF5eIaeyfWnbiUV4D4dW4/cYBkq8bzmhsEeR9fXNt CRveuIdnvsE3qNOdpPbDurY6gnSwMQnbPiO9MIuNCEyWVZ529FaiN6PXwg3WZcWUQ+InycVdnCp lckgPY+rrNwwrp37YIfwo1Y2A4Qcg5CsQBfidtN7zuPryJa+8BDoR2WrPMS/wsGkeSqiFY4dMzL tct1U694ziLxVkjELOemacB9LeLvFn8bLTCO+SiBByzJUesynSd3RFJ2713+vj0CT2bRAn424jR pkl5SZEuv9DU5m0WVcaRiwWAKsxeHbSr3UYNCX/oO2Y04tGlguH4YmLh+v6/S3/iM87Xk0usRPL 2cFLBH0B4aZYW61UvVVN30BMW1fP21fVKi218S X-Received: by 2002:a05:7022:6713:b0:12b:ec15:69d3 with SMTP id a92af1059eb24-12bfb74944dmr5473553c88.19.1775496300585; Mon, 06 Apr 2026 10:25:00 -0700 (PDT) Received: from mozart.vkv.me ([2001:5a8:468b:d015:5800:9be1:f8c2:9030]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12bede7f542sm12030905c88.14.2026.04.06.10.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2026 10:25:00 -0700 (PDT) Date: Mon, 6 Apr 2026 10:24:57 -0700 From: Calvin Owens To: Michael Byczkowski Cc: giometti@enneenne.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org Subject: Re: [PATCH] pps: improve PREEMPT_RT performance Message-ID: References: <0D0865AB-8578-4D25-BE04-0933326E1F17@by-online.de> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0D0865AB-8578-4D25-BE04-0933326E1F17@by-online.de> On Monday 04/06 at 14:11 +0200, 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. Hi Michael, Thanks for working on this, and for the nice clean patches :) Your series is happily running on my pps-gpio setup. When you resend the patches, feel free to add: Tested-by: Calvin Owens One quick thought below: > 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 > > [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 These should be combined into one commit to avoid bisection problems, the intermediate states don't compile. But maybe you already intend to do that, I see you've grouped them together here. Cheers, Calvin