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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).