From: Chen Gong <gong.chen@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
tony.luck@intel.com, bp@amd64.org, x86@kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [patch 1/2] x86: mce Cleanup timer mess
Date: Mon, 04 Jun 2012 10:22:28 +0800 [thread overview]
Message-ID: <4FCC1BE4.3070404@linux.intel.com> (raw)
In-Reply-To: <20120524175056.391516712@linutronix.de>
Hi, Tony and Thomas
This patch has been merged, but It still have some confusion, please
see inline comment and give me some explanation.
于 2012/5/25 1:54, Thomas Gleixner 写道:
> Use unsigned long for dealing with jiffies not int. Rename the
> callback to something sensible. Use __this_cpu_read/write for
> accessing per cpu data.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> ---
> arch/x86/kernel/cpu/mcheck/mce.c | 31
> ++++++++++++++++--------------- 1 file changed, 16 insertions(+),
> 15 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/cpu/mcheck/mce.c
> ===================================================================
>
>
>
--- linux-2.6.orig/arch/x86/kernel/cpu/mcheck/mce.c
> +++ linux-2.6/arch/x86/kernel/cpu/mcheck/mce.c @@ -1237,15
> +1237,15 @@ void mce_log_therm_throt_event(__u64 sta * poller finds
> an MCE, poll 2x faster. When the poller finds no more * errors,
> poll 2x slower (up to check_interval seconds). */ -static int
> check_interval = 5 * 60; /* 5 minutes */ +static unsigned long
> check_interval = 5 * 60; /* 5 minutes */
>
> -static DEFINE_PER_CPU(int, mce_next_interval); /* in jiffies */
> +static DEFINE_PER_CPU(unsigned long, mce_next_interval); /* in
> jiffies */ static DEFINE_PER_CPU(struct timer_list, mce_timer);
>
> -static void mce_start_timer(unsigned long data) +static void
> mce_timer_fn(unsigned long data) { - struct timer_list *t =
> &per_cpu(mce_timer, data); - int *n; + struct timer_list *t =
> &__get_cpu_var(mce_timer); + unsigned long iv;
>
> WARN_ON(smp_processor_id() != data);
>
> @@ -1258,13 +1258,14 @@ static void mce_start_timer(unsigned lon *
> Alert userspace if needed. If we logged an MCE, reduce the *
> polling interval, otherwise increase the polling interval. */ - n
> = &__get_cpu_var(mce_next_interval); + iv =
> __this_cpu_read(mce_next_interval); if (mce_notify_irq()) - *n =
> max(*n/2, HZ/100); + iv = max(iv, (unsigned long) HZ/100);
Here Thomas changed original mode from "*n = max(*n/2, HZ/100);"
to "iv = max(iv, (unsigned long) HZ/100);", which means *iv* will not
be decremented but only incremented in _else_ branch. If so, eventually
the *iv will be equal to *check_interval*. I don't think it makes sense.
Even we use new logic, the comment before these codes should be updated.
So Thomas, would you please explain why you use this new logic?
> else - *n = min(*n*2,
> (int)round_jiffies_relative(check_interval*HZ)); + iv = min(iv *
> 2, round_jiffies_relative(check_interval * HZ)); +
> __this_cpu_write(mce_next_interval, iv);
>
> - t->expires = jiffies + *n; + t->expires = jiffies + iv;
> add_timer_on(t, smp_processor_id()); }
>
> @@ -1542,17 +1543,17 @@ static void __mcheck_cpu_init_vendor(str
> static void __mcheck_cpu_init_timer(void) { struct timer_list *t =
> &__get_cpu_var(mce_timer); - int *n =
> &__get_cpu_var(mce_next_interval); + unsigned long iv =
> __this_cpu_read(mce_next_interval);
>
> - setup_timer(t, mce_start_timer, smp_processor_id()); +
> setup_timer(t, mce_timer_fn, smp_processor_id());
>
> if (mce_ignore_ce) return;
>
> - *n = check_interval * HZ; - if (!*n) +
> __this_cpu_write(mce_next_interval, iv); + if (!iv) return; -
> t->expires = round_jiffies(jiffies + *n); + t->expires =
> round_jiffies(jiffies + iv); add_timer_on(t, smp_processor_id());
> }
>
> @@ -2262,7 +2263,7 @@ mce_cpu_callback(struct notifier_block *
> case CPU_DOWN_FAILED_FROZEN: if (!mce_ignore_ce && check_interval)
> { t->expires = round_jiffies(jiffies + -
> __get_cpu_var(mce_next_interval)); +
> per_cpu(mce_next_interval, cpu)); add_timer_on(t, cpu); }
> smp_call_function_single(cpu, mce_reenable_cpu, &action, 1);
>
>
>
next prev parent reply other threads:[~2012-06-04 2:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 17:54 [patch 0/2] x86: mce: Implement poll mode for CMCI Thomas Gleixner
2012-05-24 17:54 ` [patch 1/2] x86: mce Cleanup timer mess Thomas Gleixner
2012-05-25 6:16 ` Borislav Petkov
2012-06-04 2:22 ` Chen Gong [this message]
2012-06-04 18:14 ` Luck, Tony
2012-06-04 19:57 ` Thomas Gleixner
2012-06-04 22:18 ` Borislav Petkov
2012-05-24 17:54 ` [patch 2/2] x86: mce: Implement cmci poll mode for intel machines Thomas Gleixner
2012-05-25 6:24 ` Borislav Petkov
2012-05-25 7:31 ` Chen Gong
2012-05-25 9:20 ` Thomas Gleixner
2012-05-25 12:17 ` Thomas Gleixner
2012-05-28 9:47 ` Chen Gong
2012-05-28 9:52 ` Chen Gong
2012-06-04 2:37 ` Chen Gong
2012-06-04 20:01 ` Thomas Gleixner
2012-06-05 11:47 ` Chen Gong
2012-06-05 12:57 ` Borislav Petkov
2012-06-06 1:36 ` Chen Gong
2012-06-06 9:04 ` Borislav Petkov
2012-06-05 13:35 ` Thomas Gleixner
2012-06-06 7:21 ` Chen Gong
2012-06-06 9:18 ` Thomas Gleixner
2012-06-06 10:23 ` Thomas Gleixner
2012-06-06 12:24 ` Chen Gong
2012-06-06 12:27 ` Peter Zijlstra
2012-06-06 14:15 ` Thomas Gleixner
2012-06-06 14:46 ` Thomas Gleixner
2012-06-07 3:32 ` Chen Gong
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=4FCC1BE4.3070404@linux.intel.com \
--to=gong.chen@linux.intel.com \
--cc=bp@amd64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.