lkml.org 
[lkml]   [2009]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RT] [RFC] simple SMI detector
On Sun, Jan 25, 2009 at 01:12:45PM +1100, Sven-Thorsten Dietrich wrote:
> Latency-friendly SMI implementations may be found in some systems, and
> not so much in others.
>
> It should be up to the promotional divisions of the particular hardware
> suppliers to assess the market pressure, and to report the performance
> advantages of their specific systems.

They definitely exist; I spent quite a bit of time working with IBM
hardware engineers on what we called "SMI remediation". In some cases
it was necessary to have some custom kernel and/or user space code to
run (at background priority) maintenance work such as predictive
failure calculations that really didn't need to be done at SMI
stop-the-OS-on-all-cpus priority, but which hardware manufacturers
would do at the SMI level to avoid needing to create
motherboard-specific device drivers and/or daemons for each OS that
they might want to support.

> I envision documentation of these specs, in a similar fashion to the
> manner in which CPU clock-cycles are documented for specific instruction
> executions - for those systems eligible (certified?) for low-latency
> operation.

I'm not sure exactly how one would do this certification, but I agree
that some kind of "real-time ready" logo/certification program would
make a huge amount of sense, with some standardized metrics of maximum
time spent in an SMI routine, and under what circumstances (in some
cases it occurs every 30-60 minutes; on other cases, only when the CPU
is about to melt itself into slag, or when there are ECC errors, etc.)
There is a huge difference between a system which stops the OS on all
CPU's dead in its tracks for milliseconds once every 45 minutes,
versus one which only triggers an SMI in extreme situations when the
hardware is about to destroy itself.

I will also note that for some applications (i.e., military hardware
running under battle conditions), where it might be that running the
hardware beyond its thermal limits might actually be *desirable*.
After all, an extra 15 minutes of running beyond thermal limits that
eventually causes the CPU to get flakey might be worth it if the
alternative is the ship getting sunk because the BIOS decided that
shutting down the CPU to save it from thermal damage was more
important than say, running the anti-aircraft guns....

- Ted


\
 
 \ /
  Last update: 2009-01-25 05:05    [W:0.096 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site