Received-SPF: pass (google.com: domain of linux-kernel+bounces-103537-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 14 Mar 2024 15:59:39 +0000
From: Mark Rutland <mark.rutland@arm.com>
To: Sagi Maimon <maimon.sagi@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, richardcochran@gmail.com,
	luto@kernel.org, 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, mszeredi@redhat.com,
	casey@schaufler-ca.com, reibax@gmail.com, davem@davemloft.net,
	brauner@kernel.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH v7] posix-timers: add clock_compare system call
Message-ID: <ZfMe66MfHBEfxrdd@FVFF77S0Q05N>
References: <20240314090540.14091-1-maimon.sagi@gmail.com>
 <87a5n1m5j1.ffs@tglx>
 <CAMuE1bH_H9E+Zx365G9AtmWSmhW-kPPB+-=8s2rH4hpxqE+dHQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMuE1bH_H9E+Zx365G9AtmWSmhW-kPPB+-=8s2rH4hpxqE+dHQ@mail.gmail.com>

On Thu, Mar 14, 2024 at 02:19:39PM +0200, Sagi Maimon wrote:
> On Thu, Mar 14, 2024 at 1:12 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Thu, Mar 14 2024 at 11:05, Sagi Maimon wrote:
> > > +     if (crosstime_support_a) {
> > > +             ktime_a = ktime_sub(xtstamp_a2.device, xtstamp_a1.device);
> > > +             ts_offs_err = ktime_divns(ktime_a, 2);
> > > +             ktime_a = ktime_add_ns(xtstamp_a1.device, (u64)ts_offs_err);
> > > +             ts_a1 = ktime_to_timespec64(ktime_a);
> >
> > This is just wrong.
> >
> >      read(a1);
> >      read(b);
> >      read(a2);
> >
> > You _CANNOT_ assume that (a1 + ((a2 - a1) / 2) is anywhere close to the
> > point in time where 'b' is read. This code is preemtible and
> > interruptible. I explained this to you before.
> >
> > Your explanation in the comment above the function is just wishful
> > thinking.
> >
> you explained it before, but still it is better then two consecutive
> user space calls which are also preemptible
> and the userspace to kernel context switch time is added.

How much "better" is that in reality?

The time for a user<->kernel transition should be trivial relative to the time
a task spends not running after having been preempted.

Either:

(a) Your userspace application can handle the arbitrary delta resulting from a
    preemption, in which case the trivial cost shouldn't matter.

    i.e. this patch *is not necessary* to solve your problem.

(b) Your userspace application cannot handle the arbitrary delta resulting from
    a preemption, in which case you need to do something to handle that, which
    you haven't described at all.
  
    i.e. with the information you have provided so far, this patch is
    *insufficient* to solve your problem.

> > > + * In other cases: Read clock_a twice (before, and after reading clock_b) and
> > > + * average these times – to be as close as possible to the time we read clock_b.
> >
> > Can you please sit down and provide a precise technical description of
> > the problem you are trying to solve and explain your proposed solution
> > at the conceptual level instead of throwing out random implementations
> > every few days?

100% agreed.

Please, explain the actual problem you are solving here. What *specifically*
are you trying to do in userspace with these values? "Synchronization" is too
vague a description.

Making what is already the best case *marginally better* without handling the
common and worst cases is a waste of time. It doesn't actually solve the
problem, and it misleads people into thinknig that a problem is solved when it
is not.

Mark.