From owner-freebsd-current@FreeBSD.ORG Sat Oct 11 23:52:02 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4DA216A4B3 for ; Sat, 11 Oct 2003 23:52:02 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id B7E5543FBF for ; Sat, 11 Oct 2003 23:52:01 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 24013 invoked by uid 1000); 12 Oct 2003 06:52:04 -0000 Date: Sat, 11 Oct 2003 23:52:04 -0700 (PDT) From: Nate Lawson To: current@freebsd.org Message-ID: <20031011234314.P23991@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Interrupt statistics? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 06:52:02 -0000 Does anyone have recent statistics for interrupt latency and arrival timings? I am very interested in our idle load characteristics. It seems most systems I've analyzed have an average idle interrupt rate of about 225 per second, dominated by the clk and rtc interrupts as shown below. clk irq0 99/sec rtc irq8 127/sec Since these are both clocks, I assume the arrival of their interrupts are equally spaced and not correlated to each other. How much latency do the handlers for these have? Are there any system processes which generate repetitive bursts of very short tasks? If so, how long do those tasks take? The reason why I ask is I'm coming up with a default policy for CPU sleep states which can have as high a latency as a few hundred microseconds. On an idle system, this should be fine although it does add to the latency for the above clock handlers. But I also need to be able to demote quickly to short sleep states (e.g., HLT) if the system is becoming active to decrease response times. Thanks for any info, Nate