lkml.org 
[lkml]   [2004]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH, 2/4] readX_check() performance evaluation


On Wed, 28 Jan 2004, Andi Kleen wrote:
>
> Where would you put the flag?
>
> Doing it global may give false errors for the wrong device with async MCEs
> and on SMP.

That entirely depends on what the hardware supports. How much information
will you get about the error?

If the real error is on the bridge somewhere but you don't even know which
CPU did the access (and just "somebody" gets an MCE), just set a global
flag, and have "read_pcix_error()" check the bridge (since it doesn't need
to look anything up - it already knows the device).

And in that case then you need to take the proper locks (per-bridge, or
global, depending on just how much you care) in "clear_pcix_error()" and
release them in "read_pcix_error()".

Alternatively, if you get a lot of information at MCE time (CPU that did
the access + some device data), just queue up the information in a per-CPU
queue. You don't have to worry about overflow - you can just drop if if
you get many errors (or maybe maintain a count), since the only thing that
matters is "we got an error for this device" along with maybe some small
amount of info on what kind(s) of error(s).

Basically: it all boils down to what the hardware offers.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.064 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site