From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755074AbZIAQPq (ORCPT ); Tue, 1 Sep 2009 12:15:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755041AbZIAQPp (ORCPT ); Tue, 1 Sep 2009 12:15:45 -0400 Received: from sj-iport-2.cisco.com ([171.71.176.71]:49035 "EHLO sj-iport-2.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755040AbZIAQPo (ORCPT ); Tue, 1 Sep 2009 12:15:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACjlnEqrR7PD/2dsb2JhbADEaYhBAZAFBYI4gWM X-IronPort-AV: E=Sophos;i="4.44,313,1249257600"; d="scan'208";a="200717978" From: Roland Dreier To: Christoph Lameter Cc: Thomas Gleixner , Gregory Haskins , Rik van Riel , Chris Friesen , raz ben yehuda , Andrew Morton , mingo@elte.hu, peterz@infradead.org, maximlevitsky@gmail.com, efault@gmx.de, wiseman@macs.biu.ac.il, linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org Subject: Re: RFC: THE OFFLINE SCHEDULER References: <1251282598.3514.20.camel@raz> <1251297910.1791.22.camel@maxim-laptop> <1251322663.3882.48.camel@raz> <4A96B997.1070001@nortel.com> <4A97071F.5070804@novell.com> <4A973DAE.4020508@redhat.com> <4A975025.8030500@novell.com> <4A975CC4.1090208@novell.com> X-Message-Flag: Warning: May contain useful information Date: Tue, 01 Sep 2009 09:15:46 -0700 In-Reply-To: (Christoph Lameter's message of "Tue, 1 Sep 2009 14:42:29 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Sep 2009 16:15:46.0338 (UTC) FILETIME=[765EB820:01CA2B1F] Authentication-Results: sj-dkim-3; header.From=rdreier@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Ok then these per cpu irqs are there to support something different? There > are per cpu irqs here. Seems to be hardware supported? Yes, the driver now creates per-cpu IRQs for completions. However if you don't trigger any completion events then you won't get any interrupts. That's different from the workqueues, which are used to poll the hardware for port changes and internal errors (and which are single-threaded and can be put on whatever "system services" CPU you want) - R.