Linux Documentation
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-pm@vger.kernel.org, x86@kernel.org,
	linux-doc@vger.kernel.org, Len Brown <len.brown@intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Aubrey Li <aubrey.li@linux.intel.com>,
	Amit Kucheria <amitk@kernel.org>, Andi Kleen <ak@linux.intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Ricardo Neri <ricardo.neri@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/7] thermal: intel: hfi: Enable notification interrupt
Date: Tue, 9 Nov 2021 09:48:07 +0100	[thread overview]
Message-ID: <YYo1x8YLozBZbqwC@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20211109022613.GA16930@ranerica-svr.sc.intel.com>

On Mon, Nov 08, 2021 at 06:26:13PM -0800, Ricardo Neri wrote:
> On Mon, Nov 08, 2021 at 10:07:40AM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 05, 2021 at 06:33:10PM -0700, Ricardo Neri wrote:

> > > +static void hfi_update_work_fn(struct work_struct *work)
> > > +{
> > > +	struct hfi_instance *hfi_instance;
> > > +
> > > +	hfi_instance = container_of(to_delayed_work(work), struct hfi_instance,
> > > +				    update_work);
> > > +	if (!hfi_instance)
> > > +		return;
> > > +
> > > +	/* TODO: Consume update here. */
> > 
> > 	// this here uses ->event_lock to serialize against the
> > 	// interrupt below changing the data...
> 
> Anyone reading the HFI table would need to take ->event_lock.

Right.. that implies ->event_lock can be taken while there is no
interrupt active, which then necessitates the additional lock.

> > > +}
> > > +
> > > +void intel_hfi_process_event(__u64 pkg_therm_status_msr_val)
> > > +{
> > > +	struct hfi_instance *hfi_instance;
> > > +	int cpu = smp_processor_id();
> > > +	struct hfi_cpu_info *info;
> > > +	unsigned long flags;
> > > +	u64 timestamp;
> > > +
> > > +	if (!pkg_therm_status_msr_val)
> > > +		return;
> > > +
> > > +	info = &per_cpu(hfi_cpu_info, cpu);
> > > +	if (!info)
> > > +		return;
> > > +
> > > +	/*
> > > +	 * It is possible that we get an HFI thermal interrupt on this CPU
> > > +	 * before its HFI instance is initialized. This is not a problem. The
> > > +	 * CPU that enabled the interrupt for this package will also get the
> > > +	 * interrupt and is fully initialized.
> > > +	 */
> > > +	hfi_instance = info->hfi_instance;
> > > +	if (!hfi_instance)
> > > +		return;
> > > +
> > 
> > 	/*
> > 	 * If someone is already handling the interrupt, we shouldn't be
> > 	 * burning time waiting for them to then do more nothing.
> > 	 */
> > 	if (!raw_spin_trylock(&hfi_instance->interrupt_lock))
> > 		return;
> > 
> > 
> > > +	raw_spin_lock_irqsave(&hfi_instance->event_lock, flags);
> 
> The CPU who acquired ->interrupt_lock successfully now will acquire
> ->event_lock to serialize writes and reads to the HFI table.

Right, so ->interrupt_lock is purely used to serialize interrupts, and
only one interrupt gets to do the update, while the others can exit and
resume with what they were doing asap, without wasting cycles spinning
on ->event_lock only to then not do anything.

> > > +	/*
> > > +	 * On most systems, all CPUs in the package receive a package-level
> > > +	 * thermal interrupt when there is an HFI update. Since they all are
> > > +	 * dealing with the same update (as indicated by the update timestamp),
> > > +	 * it is sufficient to let a single CPU to acknowledge the update and
> > > +	 * schedule work to process it.
> > > +	 */
> > > +	timestamp = *(u64 *)hfi_instance->hw_table;
> > > +	if (hfi_instance->timestamp >= timestamp)
> > > +		goto unlock_spinlock;
> > 
> > This can go the way of the dodo.
> 
> (I guess I can still check the timestamp in case buggy firmware triggers
> updates with the same timestamp, right?)

Sure..

> > 
> > > +
> > > +	hfi_instance->timestamp = timestamp;
> > > +
> > > +	memcpy(hfi_instance->table_base, hfi_instance->hw_table,
> > > +	       hfi_features.nr_table_pages << PAGE_SHIFT);

I think we actually need to release ->interrupt_lock here, *before* the
WRMSR that ACKs the HFI update. Because I think the moment that WRMSR
goes through we can get another interrupt, and that *must* not find
->interrupt_lock taken, otherwise it will not process the update etc..
leading to lost interrupts.

> > > +	/*
> > > +	 * Let hardware and other CPUs know that we are done reading the HFI
> > > +	 * table and it is free to update it again.
> > > +	 */
> > > +	pkg_therm_status_msr_val &= THERM_STATUS_CLEAR_PKG_MASK &
> > > +				    ~PACKAGE_THERM_STATUS_HFI_UPDATED;
> > > +	wrmsrl(MSR_IA32_PACKAGE_THERM_STATUS, pkg_therm_status_msr_val);
> > > +	schedule_delayed_work(&hfi_instance->update_work, HFI_UPDATE_INTERVAL);
> > > +
> > > +unlock_spinlock:
> > > +	raw_spin_unlock_irqrestore(&hfi_instance->event_lock, flags);
> > 
> > 	raw_spin_unlock(&hfi_instance->interrupt_lock);
> 
> ... and here we release both locks.

See above.

  reply	other threads:[~2021-11-09  8:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-06  1:33 [PATCH 0/7] Thermal: Introduce the Hardware Feedback Interface for thermal and performance management Ricardo Neri
2021-11-06  1:33 ` [PATCH 1/7] x86/Documentation: Describe the Intel Hardware Feedback Interface Ricardo Neri
2021-11-30  9:24   ` Daniel Lezcano
2021-11-30 10:20     ` Srinivas Pandruvada
2021-11-06  1:33 ` [PATCH 2/7] x86: Add definitions for " Ricardo Neri
2021-11-06 10:30   ` Borislav Petkov
2021-11-06 22:01     ` Ricardo Neri
2021-11-06  1:33 ` [PATCH 3/7] thermal: intel: hfi: Minimally initialize the " Ricardo Neri
2021-11-08  8:47   ` Peter Zijlstra
2021-11-09  2:28     ` Ricardo Neri
2021-11-24 14:09   ` Rafael J. Wysocki
2021-11-30  3:20     ` Ricardo Neri
2021-11-30  3:55       ` Srinivas Pandruvada
2021-11-30 13:45         ` Ricardo Neri
2021-11-06  1:33 ` [PATCH 4/7] thermal: intel: hfi: Handle CPU hotplug events Ricardo Neri
2021-11-24 14:48   ` Rafael J. Wysocki
2021-11-30 13:21     ` Ricardo Neri
2021-11-30 13:32       ` Rafael J. Wysocki
2021-12-02 23:43         ` Ricardo Neri
2021-11-06  1:33 ` [PATCH 5/7] thermal: intel: hfi: Enable notification interrupt Ricardo Neri
2021-11-08  9:01   ` Peter Zijlstra
2021-11-09 15:00     ` Ricardo Neri
2021-11-08  9:07   ` Peter Zijlstra
2021-11-09  2:26     ` Ricardo Neri
2021-11-09  8:48       ` Peter Zijlstra [this message]
2021-11-09 12:54         ` Srinivas Pandruvada
2021-11-06  1:33 ` [PATCH 6/7] thermal: netlink: Add a new event to notify CPU capabilities change Ricardo Neri
2021-11-09 12:39   ` Lukasz Luba
2021-11-09 13:23     ` Srinivas Pandruvada
2021-11-09 13:53       ` Lukasz Luba
2021-11-09 14:15         ` Srinivas Pandruvada
2021-11-09 17:51           ` Lukasz Luba
2021-11-09 21:25             ` Srinivas Pandruvada
2021-11-30  9:29   ` Daniel Lezcano
2021-12-09 16:03     ` Ricardo Neri
2021-12-09 16:57       ` Daniel Lezcano
2021-12-09 17:39         ` Srinivas Pandruvada
2021-11-06  1:33 ` [PATCH 7/7] thermal: intel: hfi: Notify user space for HFI events Ricardo Neri
2021-11-24 15:18   ` Rafael J. Wysocki
2021-11-26  6:23     ` Srinivas Pandruvada

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=YYo1x8YLozBZbqwC@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=ak@linux.intel.com \
    --cc=amitk@kernel.org \
    --cc=aubrey.li@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=ricardo.neri@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tim.c.chen@linux.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