From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Masters Subject: Re: [RT] [RFC] simple SMI detector Date: Sun, 25 Jan 2009 16:41:20 -0500 Message-ID: <1232919680.1326.11.camel@jcmlaptop> References: <1232751312.3990.59.camel@perihelion.bos.jonmasters.org> <75b66ecd0901231833j2fda4554sb0f47457ab838566@mail.gmail.com> <1232845026.3990.71.camel@perihelion.bos.jonmasters.org> <1232849565.29318.112.camel@sven.thebigcorporation.com> <20090125040246.GE9216@mit.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Sven-Thorsten Dietrich , Thomas Gleixner , Lee Revell , linux-rt-users@vger.kernel.org, LKML , williams , "Luis Claudio R. Goncalves" To: Theodore Tso Return-path: In-Reply-To: <20090125040246.GE9216@mit.edu> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-rt-users.vger.kernel.org On Sat, 2009-01-24 at 23:02 -0500, Theodore Tso wrote: > 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 actually already talked to a certain industry group about a different program but will mention this idea also - some kind of industry notion of "real time platform" probably wouldn't be a bad idea. I'm not sure what the vendors would say/think, but it's probably worth having the discussion anyway. I think we're all right now having to do a lot of legwork in testing/certifying that systems have acceptable latencies. Jon.