Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1702174 > unrolled thread

[PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback

Started byDenis Plotnikov <dplotnikov@virtuozzo.com>
First post2017-08-02 17:00 +0200
Last post2017-08-02 19:30 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback Denis Plotnikov <dplotnikov@virtuozzo.com> - 2017-08-02 17:00 +0200
    Re: [PATCH v4 01/10] timekeeper: introduce extended clocksource  reading callback John Stultz <john.stultz@linaro.org> - 2017-08-02 19:20 +0200
      Re: [PATCH v4 01/10] timekeeper: introduce extended clocksource  reading callback Paolo Bonzini <pbonzini@redhat.com> - 2017-08-02 19:30 +0200

#1702174 — [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback

FromDenis Plotnikov <dplotnikov@virtuozzo.com>
Date2017-08-02 17:00 +0200
Subject[PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback
Message-ID<ua3hT-2KU-15@gated-at.bofh.it>
The callback provides extended information about just read
clocksource value.

It's going to be used in cases when detailed system information
needed for further time related values calculation, e.g in KVM
masterclock settings calculation.

Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
---
 include/linux/clocksource.h | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index a78cb18..786a522 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -48,7 +48,14 @@ struct module;
  *			400-499: Perfect
  *				The ideal clocksource. A must-use where
  *				available.
- * @read:		returns a cycle value, passes clocksource as argument
+ * @read:		returns a cycle value (might be not quite cycles:
+ *			see pvclock) passes clocksource as argument
+ * @read_with_stamp:	saves cycles value (got from timekeeper) and cycles
+ *			stamp (got from hardware counter value and used by
+ *			timekeeper to calculate the cycles value) to
+ *			corresponding input pointers return true if cycles
+ *			stamp holds real cycles and false if it holds some
+ *			time derivative value
  * @enable:		optional function to enable the clocksource
  * @disable:		optional function to disable the clocksource
  * @mask:		bitmask for two's complement
@@ -78,6 +85,8 @@ struct module;
  */
 struct clocksource {
 	u64 (*read)(struct clocksource *cs);
+	bool (*read_with_stamp)(struct clocksource *cs,
+				u64 *cycles, u64 *cycles_stamp);
 	u64 mask;
 	u32 mult;
 	u32 shift;
-- 
2.7.4

[toc] | [next] | [standalone]


#1702290 — Re: [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback

FromJohn Stultz <john.stultz@linaro.org>
Date2017-08-02 19:20 +0200
SubjectRe: [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback
Message-ID<ua5to-4lS-13@gated-at.bofh.it>
In reply to#1702174
On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov
<dplotnikov@virtuozzo.com> wrote:
> The callback provides extended information about just read
> clocksource value.
>
> It's going to be used in cases when detailed system information
> needed for further time related values calculation, e.g in KVM
> masterclock settings calculation.
>
> Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
> ---
>  include/linux/clocksource.h | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index a78cb18..786a522 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -48,7 +48,14 @@ struct module;
>   *                     400-499: Perfect
>   *                             The ideal clocksource. A must-use where
>   *                             available.
> - * @read:              returns a cycle value, passes clocksource as argument
> + * @read:              returns a cycle value (might be not quite cycles:
> + *                     see pvclock) passes clocksource as argument
> + * @read_with_stamp:   saves cycles value (got from timekeeper) and cycles
> + *                     stamp (got from hardware counter value and used by
> + *                     timekeeper to calculate the cycles value) to
> + *                     corresponding input pointers return true if cycles
> + *                     stamp holds real cycles and false if it holds some
> + *                     time derivative value
>   * @enable:            optional function to enable the clocksource
>   * @disable:           optional function to disable the clocksource
>   * @mask:              bitmask for two's complement
> @@ -78,6 +85,8 @@ struct module;
>   */
>  struct clocksource {
>         u64 (*read)(struct clocksource *cs);
> +       bool (*read_with_stamp)(struct clocksource *cs,
> +                               u64 *cycles, u64 *cycles_stamp);
>         u64 mask;

I'm not really fan of an interface that leaks magic data to users that
know enough.

And its not clear from this if the magic data is standardized or
different clocksources export different data?

What exactly are the attributes you're trying to pull from the
lower-level hardware that you can't get otherwise (without using the
update_pvclock_gtod() since, if I'm understanding that apparently
gives you too much detail to deal with)?

thanks
-john

[toc] | [prev] | [next] | [standalone]


#1702318 — Re: [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback

FromPaolo Bonzini <pbonzini@redhat.com>
Date2017-08-02 19:30 +0200
SubjectRe: [PATCH v4 01/10] timekeeper: introduce extended clocksource reading callback
Message-ID<ua5D5-4rG-27@gated-at.bofh.it>
In reply to#1702290
On 02/08/2017 19:08, John Stultz wrote:
>> +       bool (*read_with_stamp)(struct clocksource *cs,
>> +                               u64 *cycles, u64 *cycles_stamp);
>>         u64 mask;
> I'm not really fan of an interface that leaks magic data to users that
> know enough.
> 
> And its not clear from this if the magic data is standardized or
> different clocksources export different data?
> 
> What exactly are the attributes you're trying to pull from the
> lower-level hardware that you can't get otherwise (without using the
> update_pvclock_gtod() since, if I'm understanding that apparently
> gives you too much detail to deal with)?

We need the exact TSC value that was used to compute the ktime.  This is
 different between TSC and kvmclock because TSC's read() callback
returns  cycles (of course), while kvmclock's read() callback returns
nanoseconds.

In turn, kvmclock's read() callback returns nanoseconds because it has
to check the read against the host-provided seqlock, so this cannot be
changed.

Paolo

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web