On Fri, Apr 27, 2007 at 02:34:11PM -0700, Tim Hockin wrote:
> From: Tim Hockin <[EMAIL PROTECTED]>
>
> Background:
> We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
> especially when we are trying really hard to stress the system out. The
> current MCE poller uses a static
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs rece
On Fri, 27 Apr 2007 13:51:28 -0700 Tim Hockin wrote:
> This is the third version of this patch. The only change from the prior
> version is to use time_after_eq().
>
> diff -pruN linux-2.6.20/arch/x86_64/kernel/mce.c
> linux-2.6.20+th/arch/x86_64/kernel/mce.c
> --- linux-2.6.20/arch/x86_64/kerne
Sorry, Gmail mangles whitespace unless you do just the right thing.
Let me work around it. Proper patch coming.
On 4/27/07, Tim Hockin <[EMAIL PROTECTED]> wrote:
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especial
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs rece
> - printk(KERN_INFO "Machine check events logged\n");
> + if ((now - last_print) >= check_interval*HZ) {
Shouldn't this use time_after() to handle wrapping?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs rece
On Fri, Apr 27, 2007 at 10:05:58AM -0700, Tim Hockin wrote:
> On 27 Apr 2007 19:02:30 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >On Fri, Apr 27, 2007 at 09:58:14AM -0700, Tim Hockin wrote:
> >> On 27 Apr 2007 11:09:17 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> >On Thu, Apr 26, 2007 at 0
On 27 Apr 2007 19:02:30 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Fri, Apr 27, 2007 at 09:58:14AM -0700, Tim Hockin wrote:
> On 27 Apr 2007 11:09:17 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
> >> Description:
> >> This patch
On Fri, Apr 27, 2007 at 09:58:14AM -0700, Tim Hockin wrote:
> On 27 Apr 2007 11:09:17 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
> >> Description:
> >> This patch makes the MCE poller adjust the polling interval dynamically.
> >> If
On 27 Apr 2007 11:09:17 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
> Description:
> This patch makes the MCE poller adjust the polling interval dynamically.
> If we find an MCE, poll 2x faster (down to 10 ms). When we stop finding
>
On Thu, Apr 26, 2007 at 06:02:52PM -0700, Tim Hockin wrote:
> Description:
> This patch makes the MCE poller adjust the polling interval dynamically.
> If we find an MCE, poll 2x faster (down to 10 ms). When we stop finding
> MCEs, poll 2x slower (up to check_interval seconds). The check_inter
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs
13 matches
Mail list logo
