Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[Arnd Bergmann]

On Monday 23 August 2010, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
> 
> The new syscall, clock_adjtime, takes two parameters, a frequency
> adjustment in parts per billion, and a pointer to a struct timespec
> containing the clock offset. If the pointer is NULL, a frequency
> adjustment is performed. Otherwise, the clock offset is immediately
> corrected by skipping to the new time value.

It looks well-implemented, and seems to be a reasonable extension
to the clock API. I'm looking forward to your ptp patches on top
of this to see how it all fits together.

For new syscalls, it's best to take linux-api on Cc. I also added
John, since he participated in the discussion.

> In addtion, the patch provides way to unregister a posix clock. This
> function is need to support posix clocks implemented as modules.

This part should probably be a separate patch, and you need to add
some form of serialization here to avoid races between the clock
system calls and the unregistration.

> diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
> index 9829646..5843f5a 100644
> --- a/kernel/posix-cpu-timers.c
> +++ b/kernel/posix-cpu-timers.c
> @@ -207,6 +207,11 @@ int posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *tp)
>  	return error;
>  }
>  
> +int posix_cpu_clock_adj(const clockid_t which_clock, int ppb,
> +			struct timespec *tp)
> +{
> +	return -EOPNOTSUPP;
> +}

EOPNOTSUPP is specific to sockets, better use -EINVAL here.

Where do you use this function?

>  /*
>   * Sample a per-thread clock for the given task.
> diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
> index ad72342..089b0d1 100644
> --- a/kernel/posix-timers.c
> +++ b/kernel/posix-timers.c
> @@ -197,6 +197,12 @@ static int common_timer_create(struct k_itimer *new_timer)
>  	return 0;
>  }
>  
> +static inline int common_clock_adj(const clockid_t which_clock, int ppb,
> +				   struct timespec *tp)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
>  static int no_timer_create(struct k_itimer *new_timer)
>  {
>  	return -EOPNOTSUPP;

So we already return -EOPNOTSUPP in some cases? The man page does not document this.
I wonder if we should change that to -EINVAL as well.

> @@ -488,6 +494,21 @@ void register_posix_clock(const clockid_t clock_id, struct k_clock *new_clock)
>  }
>  EXPORT_SYMBOL_GPL(register_posix_clock);
>  
> +void unregister_posix_clock(const clockid_t clock_id)
> +{
> +	struct k_clock *clock;
> +
> +	if ((unsigned) clock_id >= MAX_CLOCKS) {
> +		pr_err("POSIX clock unregister failed for clock_id %d\n",
> +		       clock_id);
> +		return;
> +	}
> +
> +	clock = &posix_clocks[clock_id];
> +	memset(clock, 0, sizeof(*clock));
> +}
> +EXPORT_SYMBOL_GPL(unregister_posix_clock);
> +

It would be possible to add locks here to serialize unregistration of a clock against
dereferencing members of posix_clocks[], but that would cause noticable overhead.
A better alternative might be to make it an RCU-protected array of pointers, and
use a rcu_assign_pointer/rcu_syncronize/kfree or call_rcu sequence in unregister_posix_clock.

Or you just live with not being able to unload this module.

	Arnd

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[Matthew Wilcox]

On Mon, Aug 23, 2010 at 02:57:26PM +0200, Arnd Bergmann wrote:
> > +static inline int common_clock_adj(const clockid_t which_clock, int ppb,
> > +				   struct timespec *tp)
> > +{
> > +	return -EOPNOTSUPP;
> > +}
> > +
> >  static int no_timer_create(struct k_itimer *new_timer)
> >  {
> >  	return -EOPNOTSUPP;
> 
> So we already return -EOPNOTSUPP in some cases? The man page does not document this.
> I wonder if we should change that to -EINVAL as well.

ENOTTY is the usual errno for "inappropriate ioctl for device".  Due to
the way this patch has been chopped up, I can't tell if that's what is
intended here.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[Arnd Bergmann]

On Monday 23 August 2010, Matthew Wilcox wrote:
> On Mon, Aug 23, 2010 at 02:57:26PM +0200, Arnd Bergmann wrote:
> > > +static inline int common_clock_adj(const clockid_t which_clock, int ppb,
> > > +                              struct timespec *tp)
> > > +{
> > > +   return -EOPNOTSUPP;
> > > +}
> > > +
> > >  static int no_timer_create(struct k_itimer *new_timer)
> > >  {
> > >     return -EOPNOTSUPP;
> > 
> > So we already return -EOPNOTSUPP in some cases? The man page does not document this.
> > I wonder if we should change that to -EINVAL as well.
> 
> ENOTTY is the usual errno for "inappropriate ioctl for device".  Due to
> the way this patch has been chopped up, I can't tell if that's what is
> intended here.

It's for the CLOCK_* syscall family, which I think is different enough from
an ioctl that ENOTTY makes no sense.

The documented return values of timer_create() are EAGAIN, EINVAL and
ENOMEM.

	Arnd

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[Roland McGrath]

EOPNOTSUPP is also called ENOTSUP in userland.  ENOTSUP is the appropriate
POSIX errno code for a situation such as a clock type that cannot be used
in a certain call (like setting when you can only read it, etc.).


Thanks,
Roland

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[john stultz]

On Mon, 2010-08-23 at 14:57 +0200, Arnd Bergmann wrote:
> On Monday 23 August 2010, Richard Cochran wrote:
> > A new syscall is introduced that allows tuning of a POSIX clock. The
> > syscall is implemented for four architectures: arm, blackfin, powerpc,
> > and x86.
> > 
> > The new syscall, clock_adjtime, takes two parameters, a frequency
> > adjustment in parts per billion, and a pointer to a struct timespec
> > containing the clock offset. If the pointer is NULL, a frequency
> > adjustment is performed. Otherwise, the clock offset is immediately
> > corrected by skipping to the new time value.
> 
> It looks well-implemented, and seems to be a reasonable extension
> to the clock API. I'm looking forward to your ptp patches on top
> of this to see how it all fits together.
> 
> For new syscalls, it's best to take linux-api on Cc. I also added
> John, since he participated in the discussion.

As I mentioned in the previous mail, I agree the new functionality
(adjusting the time by an offset instantaneously) is useful, but I'd
prefer it be done initially within the existing adjtimex() interface.

Then if the posix-time clock_id multiplexing version of adjtimex is
found to be necessary, the new syscall should be introduced, using the
same API (not all clock_ids need to support all the adjtimex modes, but
the new interface should be sufficient for NTPd to use).


There are some other conceptual issues this new syscall introduces:

1) While clock_adjtimex(CLOCK_REALTIME,...) would be equivalent to
adjtimex(), would clock_adjtimex(CLOCK_MONOTONIC,...) make sense? 

Given CLOCK_MONOTONIC and CLOCK_REALTIME are both based off the same
notion of time, but offset from each other, any adjustment to one clock
would be reflected in the other. However, the API would make it seem
like they could be adjusted independently.

2) The same issue in #1 exists for CLOCK_REALTIME/MONOTONIC_COARSE
variants. 

3) Freq steering for MONOTONIC_RAW would defeat the purpose of the
clock_id.

4) Does adjustments to CPU_TIME clock_ids make sense?

I'm guessing "no" is the right call to all of the above, but am
interested if others see it differently.

thanks
-john

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[Richard Cochran]

On Mon, Aug 23, 2010 at 01:41:13PM -0700, john stultz wrote:
> As I mentioned in the previous mail, I agree the new functionality
> (adjusting the time by an offset instantaneously) is useful, but I'd
> prefer it be done initially within the existing adjtimex() interface.

But the adjtimex does not support nanosecond resolution.
 
> Then if the posix-time clock_id multiplexing version of adjtimex is
> found to be necessary, the new syscall should be introduced, using the
> same API (not all clock_ids need to support all the adjtimex modes, but
> the new interface should be sufficient for NTPd to use).

Would the new syscall need to take a struct timex?

If so, I think it not worth the effort of adding a syscall. Instead,
we can just add "clockid" flags into the mode field.

> There are some other conceptual issues this new syscall introduces:
> 
> 1) While clock_adjtimex(CLOCK_REALTIME,...) would be equivalent to
> adjtimex(), would clock_adjtimex(CLOCK_MONOTONIC,...) make sense? 
> 
> Given CLOCK_MONOTONIC and CLOCK_REALTIME are both based off the same
> notion of time, but offset from each other, any adjustment to one clock
> would be reflected in the other. However, the API would make it seem
> like they could be adjusted independently.

You could adjust the frequency of either one. As a side effect, the
other clock would also be adjusted.

You can only change the time offset on CLOCK_REALTIME, and that would
have no effect on CLOCK_MONOTONIC.

> 2) The same issue in #1 exists for CLOCK_REALTIME/MONOTONIC_COARSE
> variants. 
> 
> 3) Freq steering for MONOTONIC_RAW would defeat the purpose of the
> clock_id.

If I understand correctly, MONOTONIC_RAW is just access to the
hardware counter?
 
> 4) Does adjustments to CPU_TIME clock_ids make sense?

Don't think so.


Thanks,
Richard

Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.

[John Stultz]

On Fri, 2010-08-27 at 13:24 +0200, Richard Cochran wrote:
> On Mon, Aug 23, 2010 at 01:41:13PM -0700, john stultz wrote:
> > As I mentioned in the previous mail, I agree the new functionality
> > (adjusting the time by an offset instantaneously) is useful, but I'd
> > prefer it be done initially within the existing adjtimex() interface.
> 
> But the adjtimex does not support nanosecond resolution.

As mentioned in the last mail, that's not the case. 

> > Then if the posix-time clock_id multiplexing version of adjtimex is
> > found to be necessary, the new syscall should be introduced, using the
> > same API (not all clock_ids need to support all the adjtimex modes, but
> > the new interface should be sufficient for NTPd to use).
> 
> Would the new syscall need to take a struct timex?
> 
> If so, I think it not worth the effort of adding a syscall. Instead,
> we can just add "clockid" flags into the mode field.

Personally I'd add the new clock_adjtime interface, since it parallels
the gettimeofday/clock_gettime() interface levels. Trying to multiplex
posix clock ids via the older interface feels a little ugly.


> > There are some other conceptual issues this new syscall introduces:
> > 
> > 1) While clock_adjtimex(CLOCK_REALTIME,...) would be equivalent to
> > adjtimex(), would clock_adjtimex(CLOCK_MONOTONIC,...) make sense? 
> > 
> > Given CLOCK_MONOTONIC and CLOCK_REALTIME are both based off the same
> > notion of time, but offset from each other, any adjustment to one clock
> > would be reflected in the other. However, the API would make it seem
> > like they could be adjusted independently.
> 
> You could adjust the frequency of either one. As a side effect, the
> other clock would also be adjusted.

This in most ways makes the most sense to me, since if CLOCK_REALTIME is
properly freq corrected, it would seem CLOCK_MONOTONIC would as well.

> You can only change the time offset on CLOCK_REALTIME, and that would
> have no effect on CLOCK_MONOTONIC.

But yes, this is another possibly valid interpretation. I don't prefer
this one, but that doesn't make it invalid. And so with the new
interface, and the possibility of multiple non-synced clocks, there are
more unfortunate subtleties like this. 


> > 3) Freq steering for MONOTONIC_RAW would defeat the purpose of the
> > clock_id.
> 
> If I understand correctly, MONOTONIC_RAW is just access to the
> hardware counter?

Not exactly. Its abstracted out a step. MONOTONIC_RAW was added as there
were other applications that were trying to get to raw hardware counters
through various means. Unfortunately that caused portability issues. So
CLOCK_MONOTONIC_RAW allows a constant freq nanosecond representation of
a hardware counter.

This is similar to what I'm hoping to find here with CLOCK_PTP.

Is there a step out that makes this interface similarly abstracted out
and easier to understand from a userland perspective?  (This is the
similar to Alan's critique that it needs to not be PTP specific). 

Additionally, I'm trying to make sure that having multiple unsynced
clocks accessible from the same top-level interface isn't going to
become a headache down the road API wise.

If we abstract CLOCK_PTP out, doesn't it in effect just be
CLOCK_REALTIME_BUTDIFFERENT?

thanks
-john