> So what resource is less limited than cpu breakpoint registers but can
> induce entry to specified code (a dtrace probe)? Bingo: main memory
> and ECC codes [2]. We can deliberately mark objects, to a precision
> of an ECC code word, as bad - but list them in a tracking table which
> the ECC handler checks for dtrace entry in preference to a real ECC
> fault.
We will never be doing this: it violates the safety constraint, in
several dimensions. (One of which you outline below.)
> The non-enabled probe cost is zero. The enabled probe cost is that
> of a) rewriting the memory area in question with deliberate bad ECC;
> a bit expensive to do (e.g.) to every packet on a 10GB link,
> (especially if a bad-ECC write is significantly slower than a normal
> write) plus b) another rewrite with good ECC, plus c) the actual
> probe code.
>
> There is a reliability downside: the tracked memory may no
> longer be checked for real faults.
> It helps if an ECC codepoint is available which is not used
> by any hardware fault (or combination of faults).
Ah, yes -- the reliability "downside". This is but one tangible way in
which this notion violates the safety constraint, and as such it will
never be used by DTrace.
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
_______________________________________________
networking-discuss mailing list
[email protected]
