mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Feng Tang <feng.tang@intel.com>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Cc: rui.zhang@intel.com, andi.kleen@intel.com, dave.hansen@intel.com,
	len.brown@intel.com, Feng Tang <feng.tang@intel.com>
Subject: Re: [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked
Date: Sat, 10 Apr 2021 11:27:11 +0200	[thread overview]
Message-ID: <87y2dq32xc.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <1617092747-15769-1-git-send-email-feng.tang@intel.com>

On Tue, Mar 30 2021 at 16:25, Feng Tang wrote:
> Normally the tsc_sync will be checked every time system enters idle state,
> but there is still caveat that a system won't enter idle, either because
> it's too busy or configured purposely to not enter idle. Setup a periodic
> timer to make sure the check is always on.

Bah. I really hate the fact that we don't have a knob to disable writes
to the TSC/TSC_ADJUST msrs. That would spare this business alltogether.

> +/*
> + * Normally the tsc_sync will be checked every time system enters idle state,
> + * but there is still caveat that a system won't enter idle, either because
> + * it's too busy or configured purposely to not enter idle.
> + *
> + * So setup a periodic timer to make sure the check is always on.
> + */
> +
> +#define SYNC_CHECK_INTERVAL		(HZ * 600)
> +static void tsc_sync_check_timer_fn(struct timer_list *unused)

I've surely mentioned this before that glueing a define without an empty
newline to a function definition is horrible to read.

> +{
> +	int next_cpu;
> +
> +	tsc_verify_tsc_adjust(false);
> +
> +	/* Loop to do the check for all onlined CPUs */

I don't see a loop here.

> +	next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);

Why raw_smp_processor_id()? What's wrong with smp_processor_id()?

> +	if (next_cpu >= nr_cpu_ids)
> +		next_cpu = cpumask_first(cpu_online_mask);
> +
> +	tsc_sync_check_timer.expires += SYNC_CHECK_INTERVAL;
> +	add_timer_on(&tsc_sync_check_timer, next_cpu);
> +}
> +
> +static int __init start_sync_check_timer(void)
> +{
> +	if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
> +		return 0;
> +
> +	timer_setup(&tsc_sync_check_timer, tsc_sync_check_timer_fn, 0);
> +	tsc_sync_check_timer.expires = jiffies + SYNC_CHECK_INTERVAL;
> +	add_timer(&tsc_sync_check_timer);
> +
> +	return 0;
> +}
> +late_initcall(start_sync_check_timer);

So right now, if someone adds 'tsc=reliable' on the kernel command line
then all of the watchdog checking, except for the idle enter TSC_ADJUST
check is disabled. The NOHZ full people are probably going to be pretty
unhappy about yet another unconditional timer they have to chase down.

So this needs some more thought.

Thanks,

        tglx

  parent reply	other threads:[~2021-04-10  9:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30  8:25 Feng Tang
2021-03-30  8:25 ` [RFC 2/2] x86/tsc: mark tsc reliable for qualified platforms Feng Tang
2021-04-10  9:27 ` Thomas Gleixner [this message]
2021-04-10  9:47   ` [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked Borislav Petkov
2021-04-10 12:11     ` [PATCH] x86/msr: Block writes to certain MSRs unconditionally Borislav Petkov
2021-04-10 14:51       ` Andy Lutomirski
2021-04-10 15:33         ` [PATCH -v1.1] " Borislav Petkov
2021-04-10 18:52       ` [PATCH] " Andi Kleen
2021-04-11  9:40         ` Borislav Petkov
2021-04-11 16:03         ` Andy Lutomirski
2021-04-11 16:43           ` Andi Kleen
2021-04-11 16:57             ` Andy Lutomirski
2021-04-11 17:03               ` Borislav Petkov
2021-04-11 23:21                 ` Andy Lutomirski
2021-04-12  9:37                   ` Borislav Petkov
2021-04-10 14:48     ` [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked Feng Tang
2021-04-10 15:38       ` Borislav Petkov
2021-04-10 18:43     ` Thomas Gleixner
2021-04-10 14:38   ` Feng Tang
2021-04-10 18:46     ` Thomas Gleixner
2021-04-11  7:21       ` Feng Tang

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=87y2dq32xc.ffs@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=andi.kleen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=feng.tang@intel.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rui.zhang@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

all inboxes | Powered by JetHome®