From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Kravetz Subject: Re: [RT] [RFC] simple SMI detector Date: Sun, 25 Jan 2009 14:52:05 -0800 Message-ID: <20090125225205.GA3783@monkey.beaverton.ibm.com> References: <1232751312.3990.59.camel@perihelion.bos.jonmasters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-rt-users@vger.kernel.org, LKML , williams , "Luis Claudio R. Goncalves" To: Jon Masters Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:53247 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbZAYWwE (ORCPT ); Sun, 25 Jan 2009 17:52:04 -0500 Content-Disposition: inline In-Reply-To: <1232751312.3990.59.camel@perihelion.bos.jonmasters.org> Sender: linux-rt-users-owner@vger.kernel.org List-ID: On Fri, Jan 23, 2009 at 05:55:12PM -0500, Jon Masters wrote: > This patch adds the module smi_detector under drivers/misc > > Code from Jon Masters with small changes from Luis Goncalves and > documentation from Clark Williams. Good work Jon. I think something like this will be helpful. Any reason why you could not do SMI detection in user level code running at the highest RT priority? If something is running at the highest RT priority, it should not be preempted by anything. Right? In the past, we discoved discovered periodic SMIs on some hardware platforms by running a user level process in an infinite loop sampling the clock and reporting unexpected delays. Of course, this does hog an entire CPU. -- Mike