[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120605125758.GD13495@aftab.osrc.amd.com>
Date: Tue, 5 Jun 2012 14:57:58 +0200
From: Borislav Petkov <bp@...64.org>
To: Chen Gong <gong.chen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, tony.luck@...el.com,
x86@...nel.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 2/2] x86: mce: Implement cmci poll mode for intel machines
On Tue, Jun 05, 2012 at 07:47:20PM +0800, Chen Gong wrote:
> > static void intel_threshold_interrupt(void)
> > {
> > + if (cmci_storm_detect())
> > + return;
> > machine_check_poll(MCP_TIMESTAMP, &__get_cpu_var(mce_banks_owned));
> > mce_notify_irq();
> > }
>
> I think cmci_storm_detect should be placed in the machine_check_poll,
> not out of it. Because machine_check_poll it the core execution logic
> for CMCI handling, in the meanwhile, poll timer and mce-inject module
> call machine_check_poll at any time.
Are you saying you need CMCI throttling for when you inject MCEs?
> If poll timer or mce-inject run too quickly, the CMCI handler has
> trouble. Whereas, if cmci_storm_detect is in the machine_check_poll,
> this kind of possibility can be avoid.
In any case, cmci_storm_detect() cannot be in machine_check_poll because
last one is generic MCE code and not Intel-only. Unless you do something
like what Thomas proposed for mce_adjust_timer where the default
function does nothing and Intel only overwrites that pointer with the
needed functionality.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists