From: Andi Kleen <ak@linux.intel.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: Re-implement MCE log ring buffer as per-CPU ring buffer
Date: Wed, 22 Apr 2009 13:11:58 +0200 [thread overview]
Message-ID: <49EEFB7E.4020605@linux.intel.com> (raw)
In-Reply-To: <1240391484.6842.474.camel@yhuang-dev.sh.intel.com>
Huang Ying wrote:
Basic concept is good and it fixes some long standing problems.
But some details need to be improved I think:
> +/*
> + * Initialize MCE per-CPU log buffer
> + */
> +static void mce_log_init(void)
> +{
> + int cpu;
> + struct mce_log_cpu *mcelog_cpu;
> +
> + if (mcelog.log_cpus)
> + return;
> + mcelog.log_cpus = kmalloc(num_possible_cpus() * sizeof(mcelog_cpu),
> + GFP_KERNEL);
> + for_each_possible_cpu(cpu) {
> + mcelog_cpu = &per_cpu(mcelog_cpus, cpu);
> + mcelog.log_cpus[cpu] = mcelog_cpu;
> + }
I don't understand why the separate allocation. Can't you just put
the whole log buffer directly into the per cpu data?
This would also make the initialization cleaner because you would need to only
initialize state for the currently initialized CPU.
> + while (!mcelog_cpu->entry[i].finished) {
> + rdtscll(now);
> + if (now - start > WRITER_TIMEOUT_CYC) {
> + memset(mcelog_cpu->entry + i, 0,
> sizeof(struct mce));
> + head = mcelog_cpu->head;
> goto timeout;
This timeout should be reported somehow, perhaps with a printk.
Also it's problematic to hardcode cycles here, i think it would
be better to use a similar scheme as the Monarch timeout
with a ndelay() and a spinunit. That is guaranteed to stay
the same even as CPU frequencies change.
> +static ssize_t mce_read(struct file *filp, char __user *inubuf, size_t usize,
> + loff_t *off)
> +{
> + char __user *ubuf = inubuf;
> + struct mce_log_cpu *mcelog_cpu;
> + int cpu, new_mce, err = 0;
> + static DEFINE_MUTEX(mce_read_mutex);
> + size_t usize_limit;
> +
> + /* Too large user buffer size may cause system not response */
Did you understand why that happens? It's worrying.
> +static ssize_t show_log_flags(struct sys_device *s,
> + struct sysdev_attribute *attr,
> + char *buf)
> +{
> + int cpu = s->id;
> + struct mce_log_cpu *mcelog_cpu = &per_cpu(mcelog_cpus, cpu);
> + unsigned flags;
> + do {
> + flags = mcelog_cpu->flags;
> + } while (cmpxchg((unsigned *)&mcelog_cpu->flags, flags, 0) != flags);
> + return sprintf(buf, "0x%x\n", flags);
> +}
> +
> static SYSDEV_ATTR(trigger, 0644, show_trigger, set_trigger);
> static SYSDEV_INT_ATTR(tolerant, 0644, tolerant);
> ACCESSOR(check_interval,check_interval,mce_restart())
> +static SYSDEV_ATTR(log_flags, 0644, show_log_flags, NULL);
Do we really need that interface? It seems rather obscure.
mcelog should get these flags anyways. Better to drop it.
-Andi
next prev parent reply other threads:[~2009-04-22 11:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 9:11 Re-implement MCE log ring buffer as per-CPU ring buffer Huang Ying
2009-04-22 9:22 ` Ingo Molnar
2009-04-22 10:16 ` Robert Richter
2009-04-22 10:19 ` Ingo Molnar
2009-04-22 11:35 ` Andi Kleen
2009-04-22 11:30 ` Andi Kleen
2009-04-24 6:06 ` Huang Ying
2009-04-24 10:09 ` Robert Richter
2009-04-24 13:36 ` Steven Rostedt
2009-04-27 7:49 ` Huang Ying
2009-04-27 7:53 ` Andi Kleen
2009-04-27 14:39 ` Steven Rostedt
2009-04-27 14:44 ` Davide Libenzi
2009-04-27 14:57 ` Steven Rostedt
2009-04-27 16:14 ` Valdis.Kletnieks
2009-04-27 17:05 ` Theodore Tso
2009-04-27 20:06 ` H. Peter Anvin
2009-04-27 14:27 ` Steven Rostedt
2009-04-27 14:36 ` Patenting kernel patches was " Andi Kleen
2009-04-27 14:49 ` Steven Rostedt
2009-04-27 15:33 ` Alan Cox
2009-04-27 0:58 ` Huang Ying
2009-04-22 11:20 ` Andi Kleen
2009-04-22 15:55 ` H. Peter Anvin
2009-04-22 15:58 ` Andi Kleen
2009-04-29 19:15 ` Re-implement MCE log ring buffer as per-CPU ring buffer II Andi Kleen
2009-04-30 7:38 ` 32bit mce unification (Re: Re-implement MCE log ring buffer as per-CPU ring buffer II) Hidetoshi Seto
2009-04-22 11:11 ` Andi Kleen [this message]
2009-04-24 5:51 ` Re-implement MCE log ring buffer as per-CPU ring buffer Huang Ying
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=49EEFB7E.4020605@linux.intel.com \
--to=ak@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=ying.huang@intel.com \
/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