From: Sagi Maimon <maimon.sagi@gmail.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: richardcochran@gmail.com, datglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, arnd@arndb.de, geert@linux-m68k.org,
peterz@infradead.org, hannes@cmpxchg.org, sohil.mehta@intel.com,
rick.p.edgecombe@intel.com, nphamcs@gmail.com,
palmer@sifive.com, keescook@chromium.org, legion@kernel.org,
mark.rutland@arm.com, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v4] posix-timers: add multi_clock_gettime system call
Date: Mon, 1 Jan 2024 10:44:55 +0200 [thread overview]
Message-ID: <CAMuE1bEuou1Bx-6c3es3+FuTguOCb+iqU=hickK5hP7wT=M6Pw@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUd=16gAYvx93EsyMaaSJ-6mLvSru8Gie48Y+_dXq5FGA@mail.gmail.com>
On Sun, Dec 31, 2023 at 11:10 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> On Sun, Dec 31, 2023 at 9:07 AM Sagi Maimon <maimon.sagi@gmail.com> wrote:
> >
> > Some user space applications need to read some clocks.
> > Each read requires moving from user space to kernel space.
> > The syscall overhead causes unpredictable delay between N clocks reads
> > Removing this delay causes better synchronization between N clocks.
> >
> > Introduce a new system call multi_clock_gettime, which can be used to measure
> > the offset between multiple clocks, from variety of types: PHC, virtual PHC
> > and various system clocks (CLOCK_REALTIME, CLOCK_MONOTONIC, etc).
> > The offset includes the total time that the driver needs to read the clock
> > timestamp.
Andy Thank you for your notes.
>
> Knowing this offset sounds quite nice, but...
>
> >
> > New system call allows the reading of a list of clocks - up to PTP_MAX_CLOCKS.
> > Supported clocks IDs: PHC, virtual PHC and various system clocks.
> > Up to PTP_MAX_SAMPLES times (per clock) in a single system call read.
> > The system call returns n_clocks timestamps for each measurement:
> > - clock 0 timestamp
> > - ...
> > - clock n timestamp
>
> Could this instead be arranged to read the actual, exact offset?
>
It can be done, but I prefer to leave it generic and consistent with
other time system calls.
In most cases the offset calculation is done in user space application
> > + kernel_tp = kernel_tp_base;
> > + for (j = 0; j < n_samples; j++) {
> > + for (i = 0; i < n_clocks; i++) {
> > + if (put_timespec64(kernel_tp++, (struct __kernel_timespec __user *)
> > + &ptp_multi_clk_get->ts[j][i])) {
> > + error = -EFAULT;
> > + goto out;
> > + }
> > + }
> > + }
>
> There are several pairs of clocks that tick at precisely same rate
> (and use the same underlying hardware clock), and the offset could be
> computed exactly instead of doing this noisy loop that is merely
> somewhat less bad than what user code could do all by itself.
You are correct, there are some PHCs on the same NIC (each per port)
that share the same HW counter/clock.
In that case it is slightly better to do the offset calculation in the
NIC driver code,
but that requires changes in each NIC driver's code.
The main thing is that the multi_clock_gettime system call is a
generic solution,
it covers that case among other cases, for example sync between two
PHCs on different NICs.
next prev parent reply other threads:[~2024-01-01 8:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 17:07 [PATCH v4] posix-timers: add multi_clock_gettime system call Sagi Maimon
2023-12-31 21:09 ` Andy Lutomirski
2024-01-01 8:44 ` Sagi Maimon [this message]
2023-12-31 22:09 ` kernel test robot
2023-12-31 23:11 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuE1bEuou1Bx-6c3es3+FuTguOCb+iqU=hickK5hP7wT=M6Pw@mail.gmail.com' \
--to=maimon.sagi@gmail.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=datglx@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=geert@linux-m68k.org \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=legion@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nphamcs@gmail.com \
--cc=palmer@sifive.com \
--cc=peterz@infradead.org \
--cc=richardcochran@gmail.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sohil.mehta@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).