xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v2 6/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT
Date: Tue, 05 Apr 2016 06:22:16 -0600	[thread overview]
Message-ID: <5703CA1802000078000E32A1@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1459259051-4943-7-git-send-email-joao.m.martins@oracle.com>

>>> On 29.03.16 at 15:44, <joao.m.martins@oracle.com> wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -43,6 +43,10 @@
>  static char __initdata opt_clocksource[10];
>  string_param("clocksource", opt_clocksource);
>  
> +/* opt_nocpuhotplug: Set if CPU hotplug isn't meant to be used */
> +static bool_t __initdata opt_nocpuhotplug;
> +boolean_param("nocpuhotplug", opt_nocpuhotplug);

If we were to have such a new option, it would need to be
accompanied by an entry in the command line option doc. But
I'm opposed to this: For one, the variable being static here
means there is nothing that actually suppresses CPU hotplug
to happen. And then I think this can, for all practical purposes,
be had by suitably using existing command line options, namely
"max_cpus=", such that set_nr_cpu_ids() won't allow for any
further CPUs to get added. Albeit I admit that if someone was
to bring down some CPU and then hotplug another one, we
might still be in trouble. So maybe the better approach would
be to fail onlining of CPUs that don't meet the criteria when
"clocksource=tsc"?

> @@ -435,6 +439,7 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
>   * PLATFORM TIMER 4: TSC
>   */
>  static bool_t clocksource_is_tsc;
> +static bool_t use_tsc_stable_bit;

__read_mostly?

> @@ -468,6 +473,11 @@ static int __init init_tsctimer(struct platform_timesource *pts)
>  
>      pts->frequency = tsc_freq;
>      clocksource_is_tsc = tsc_reliable;
> +    use_tsc_stable_bit = clocksource_is_tsc &&
> +        ((nr_cpu_ids == num_present_cpus()) || opt_nocpuhotplug);

See my remark above regarding the reliability of this.

> @@ -1431,6 +1443,22 @@ static void time_calibration_std_rendezvous(void *_r)
>      raise_softirq(TIME_CALIBRATE_SOFTIRQ);
>  }
>  
> +/*
> + * Rendezvous function used when clocksource is TSC and
> + * no CPU hotplug will be performed.
> + */
> +static void time_calibration_nop_rendezvous(void *_r)

Even if done so in existing code - no new local variable or function
parameters starting with an underscore please.

> +{
> +    struct cpu_calibration *c = &this_cpu(cpu_calibration);
> +    struct calibration_rendezvous *r = _r;

const

> +    c->local_tsc_stamp = r->master_tsc_stamp;
> +    c->stime_local_stamp = get_s_time();
> +    c->stime_master_stamp = r->master_stime;
> +
> +    raise_softirq(TIME_CALIBRATE_SOFTIRQ);
> +}

Perhaps this whole function should move up ahead of the other
two, so that they both can use this one instead of now duplicating
the same code a 3rd time? Or maybe a new helper function would
be better, to also account for the difference in what
c->local_tsc_stamp gets set from (which could then become a
parameter of that new function).

> @@ -1440,6 +1468,13 @@ static void time_calibration(void *unused)
>          .semaphore = ATOMIC_INIT(0)
>      };
>  
> +    if ( use_tsc_stable_bit )
> +    {
> +        local_irq_disable();
> +        r.master_stime = read_platform_stime(&r.master_tsc_stamp);
> +        local_irq_enable();
> +    }

So this can't be in time_calibration_nop_rendezvous() because
you want to avoid the actual rendezvousing. But isn't the then
possibly much larger gap between read_platform_stime() (which
parallels the rdtsc()-s in the other two cases) and get_s_time()
invocation going to become a problem?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-04-05 12:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 13:44 [PATCH v2 0/6] x86/time: PVCLOCK_TSC_STABLE_BIT support Joao Martins
2016-03-29 13:44 ` [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info Joao Martins
2016-03-30 15:49   ` Ian Jackson
2016-03-30 16:33     ` Joao Martins
2016-03-31  7:09     ` Jan Beulich
2016-03-31  7:13   ` Jan Beulich
2016-03-31 11:04     ` Joao Martins
2016-04-05 10:16   ` Jan Beulich
2016-04-05 10:59     ` Joao Martins
2016-03-29 13:44 ` [PATCH v2 2/6] x86/time: refactor init_platform_time() Joao Martins
2016-04-01 16:10   ` Konrad Rzeszutek Wilk
2016-04-01 18:26     ` Joao Martins
2016-04-05 10:09   ` Jan Beulich
2016-04-05 10:55     ` Joao Martins
2016-04-05 11:16       ` Jan Beulich
2016-03-29 13:44 ` [PATCH v2 3/6] x86/time: implement tsc as clocksource Joao Martins
2016-03-29 17:39   ` Konrad Rzeszutek Wilk
2016-03-29 17:52     ` Joao Martins
2016-04-01 16:43   ` Konrad Rzeszutek Wilk
2016-04-01 18:38     ` Joao Martins
2016-04-01 18:45       ` Konrad Rzeszutek Wilk
2016-04-03 18:47         ` Joao Martins
2016-04-05 10:43   ` Jan Beulich
2016-04-05 14:56     ` Joao Martins
2016-04-05 15:12       ` Jan Beulich
2016-04-05 17:07         ` Joao Martins
2016-03-29 13:44 ` [PATCH v2 4/6] x86/time: streamline platform time init on plt_init() Joao Martins
2016-04-05 11:46   ` Jan Beulich
2016-04-05 15:12     ` Joao Martins
2016-04-05 15:22       ` Jan Beulich
2016-04-05 17:17         ` Joao Martins
2016-03-29 13:44 ` [PATCH v2 5/6] x86/time: refactor read_platform_stime() Joao Martins
2016-04-01 18:32   ` Konrad Rzeszutek Wilk
2016-04-05 11:52   ` Jan Beulich
2016-04-05 15:22     ` Joao Martins
2016-04-05 15:26       ` Jan Beulich
2016-04-05 17:08         ` Joao Martins
2016-03-29 13:44 ` [PATCH v2 6/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT Joao Martins
2016-04-05 12:22   ` Jan Beulich [this message]
2016-04-05 21:34     ` Joao Martins
2016-04-07 15:58       ` Jan Beulich
2016-04-07 21:17         ` Joao Martins
2016-04-07 21:32           ` Jan Beulich

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=5703CA1802000078000E32A1@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=joao.m.martins@oracle.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.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 NNTP newsgroup(s).