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

Groups > linux.kernel > #1232417 > unrolled thread

[PATCH] x86: Fix thermal throttling reporting after kexec

Back to article view | Back to linux.kernel

Contents

  [PATCH] x86: Fix thermal throttling reporting after kexec Andi Kleen <andi@firstfloor.org> - 2015-09-24 22:20 +0200
    Re: [PATCH] x86: Fix thermal throttling reporting after kexec Thomas Gleixner <tglx@linutronix.de> - 2015-10-01 14:20 +0200
      Re: [PATCH] x86: Fix thermal throttling reporting after kexec Andi Kleen <ak@linux.intel.com> - 2015-10-01 19:30 +0200
        Re: [PATCH] x86: Fix thermal throttling reporting after kexec Thomas Gleixner <tglx@linutronix.de> - 2015-10-01 23:50 +0200
          Re: [PATCH] x86: Fix thermal throttling reporting after kexec Andi Kleen <andi@firstfloor.org> - 2015-10-02 00:00 +0200
            Re: [PATCH] x86: Fix thermal throttling reporting after kexec Andi Kleen <ak@linux.intel.com> - 2015-10-02 00:10 +0200
              Re: [PATCH] x86: Fix thermal throttling reporting after kexec Thomas Gleixner <tglx@linutronix.de> - 2015-10-02 22:40 +0200

#1232417 — [PATCH] x86: Fix thermal throttling reporting after kexec

From: Andi Kleen <ak@linux.intel.com>

The per CPU thermal vector init code checks if the thermal
vector is already installed and complains and bails out if
it is.

This happens after kexec, as kernel shut down does
not clear the thermal vector APIC register.

This causes two problems:

So we always do not fully initialize thermal reports
after kexec. The CPU is still likely initialized,
as the previous kernel should have done it. But
we don't set up the software pointer to the thermal
vector, so reporting may end up with a unknown thermal
interrupt message.

Also it complains for every logical CPU, even though the
value is actually derived from BP only.

The problem is that we end up with one message per CPU,
so on larger systems it becomes very noisy and messes up
the otherwise nicely formatted CPU bootup numbers in
the kernel log.

Just remove the check. I checked the code and there's
no valid code paths where the thermal init code for a CPU
could be called multiple times.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 arch/x86/kernel/cpu/mcheck/therm_throt.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 1af51b1..2c5aaf8 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -503,14 +503,6 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 		return;
 	}
 
-	/* Check whether a vector already exists */
-	if (h & APIC_VECTOR_MASK) {
-		printk(KERN_DEBUG
-		       "CPU%d: Thermal LVT vector (%#x) already installed\n",
-		       cpu, (h & APIC_VECTOR_MASK));
-		return;
-	}
-
 	/* early Pentium M models use different method for enabling TM2 */
 	if (cpu_has(c, X86_FEATURE_TM2)) {
 		if (c->x86 == 6 && (c->x86_model == 9 || c->x86_model == 13)) {
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1237360

On Thu, 24 Sep 2015, Andi Kleen wrote:
> The per CPU thermal vector init code checks if the thermal
> vector is already installed and complains and bails out if
> it is.
> 
> This happens after kexec, as kernel shut down does
> not clear the thermal vector APIC register.

So the obvious question is, why don't we do that.

> Just remove the check. I checked the code and there's
> no valid code paths where the thermal init code for a CPU
> could be called multiple times.

I'm not against removing that check as it does not really add value,
but we still should clear the APIC register at shut down, right?

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1237588

On Thu, Oct 01, 2015 at 02:15:54PM +0200, Thomas Gleixner wrote:
> On Thu, 24 Sep 2015, Andi Kleen wrote:
> > The per CPU thermal vector init code checks if the thermal
> > vector is already installed and complains and bails out if
> > it is.
> > 
> > This happens after kexec, as kernel shut down does
> > not clear the thermal vector APIC register.
> 
> So the obvious question is, why don't we do that.

It wouldn't help if the previous kernel is some older kernel.

> 
> > Just remove the check. I checked the code and there's
> > no valid code paths where the thermal init code for a CPU
> > could be called multiple times.
> 
> I'm not against removing that check as it does not really add value,
> but we still should clear the APIC register at shut down, right?

The vector register is really harmless by itself and apart from
bogus checking it's not really affecting anyone. It may make
more sense to disable thermal reporting on shut down though.

I can add that, although it would only be useful for the more
theoretical case when you boot non Linux after kexec (as normal
Linux always reenables it anyways)

But the check should still be removed imho.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1237766

On Thu, 1 Oct 2015, Andi Kleen wrote:
> On Thu, Oct 01, 2015 at 02:15:54PM +0200, Thomas Gleixner wrote:
> > On Thu, 24 Sep 2015, Andi Kleen wrote:
> > > The per CPU thermal vector init code checks if the thermal
> > > vector is already installed and complains and bails out if
> > > it is.
> > > 
> > > This happens after kexec, as kernel shut down does
> > > not clear the thermal vector APIC register.
> > 
> > So the obvious question is, why don't we do that.
> 
> It wouldn't help if the previous kernel is some older kernel.

I know.
 
> > 
> > > Just remove the check. I checked the code and there's
> > > no valid code paths where the thermal init code for a CPU
> > > could be called multiple times.
> > 
> > I'm not against removing that check as it does not really add value,
> > but we still should clear the APIC register at shut down, right?
> 
> The vector register is really harmless by itself and apart from
> bogus checking it's not really affecting anyone. It may make
> more sense to disable thermal reporting on shut down though.
> 
> I can add that, although it would only be useful for the more
> theoretical case when you boot non Linux after kexec (as normal
> Linux always reenables it anyways)

I see it under the correctness aspect. Mop up before you shut down.
 
> But the check should still be removed imho.

As I said before: I have no objections against that.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1237770

> I see it under the correctness aspect. Mop up before you shut down.

Ok. I suspect if you want to clean up all registers there's much more
to do.

BTW there's a small danger in it: if we ever crash accessing on
of those registers panic may end up looping.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1237776

On Thu, Oct 01, 2015 at 11:50:00PM +0200, Andi Kleen wrote:
> > I see it under the correctness aspect. Mop up before you shut down.
> 
> Ok. I suspect if you want to clean up all registers there's much more
> to do.
> 
> BTW there's a small danger in it: if we ever crash accessing on
> of those registers panic may end up looping.

I thought more about it. Since this is per logical CPU state
the cleanup cannot be done in a normal shutdown callback (which
only runs on one CPU), but needs some kind of global IPI/NMI.

IPI could deadlock, so it would need to be NMI.

KVM already has one, but would need to re-organize that into
first into a generic callback infrastructure.

I don't think so much change is worth it for this one
somewhat dubious case. NMI code is also tricky and it's
probably better to keep the shut down paths as simple
and reliable as possible. Do you agree?

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1238598

On Thu, 1 Oct 2015, Andi Kleen wrote:
> On Thu, Oct 01, 2015 at 11:50:00PM +0200, Andi Kleen wrote:
> > > I see it under the correctness aspect. Mop up before you shut down.
> > 
> > Ok. I suspect if you want to clean up all registers there's much more
> > to do.
> > 
> > BTW there's a small danger in it: if we ever crash accessing on
> > of those registers panic may end up looping.
> 
> I thought more about it. Since this is per logical CPU state
> the cleanup cannot be done in a normal shutdown callback (which
> only runs on one CPU), but needs some kind of global IPI/NMI.
> 
> IPI could deadlock, so it would need to be NMI.
> 
> KVM already has one, but would need to re-organize that into
> first into a generic callback infrastructure.
> 
> I don't think so much change is worth it for this one
> somewhat dubious case. NMI code is also tricky and it's
> probably better to keep the shut down paths as simple
> and reliable as possible. Do you agree?

Yes. Makes sense.

Thanks for analysing it.

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web