From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Raymond Date: Thu, 24 Mar 2005 14:50:50 +0000 Subject: Re: [PATCH] User Level Interrupts Message-Id: <20050324085047.F110444@goliath.americas.sgi.com> List-Id: References: <20050323103832.A108873@goliath.americas.sgi.com> <20050323145738.A29828@unix-os.sc.intel.com> In-Reply-To: <20050323145738.A29828@unix-os.sc.intel.com>; from ashok.raj@intel.com on Wed, Mar 23, 2005 at 02:57:39PM -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ashok Raj Cc: "Luck, Tony" , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org I did the test you suggested. The turning-on and turning-off appeared to work but our SN Hub ASIC still sent interrupts to the specific CPU. I looked at my code again and from your description of Hotplug I do not see any conflicts. Thanks, Michael On Wed, Mar 23, 2005 at 02:57:39PM -0800, Ashok Raj wrote: > Hi Michael > > have you thought about how this infrastructure would play well with > existing CPU hotplug code for ia64? > > Once you return to user mode via the iret, is it possible that user mode > thread could get switched due to a pending cpu quiese attempt to remove > a cpu? (Current cpu removal code would bring the entire system to knees > by scheduling a high priority thread and looping with intr disabled, until the > target cpu is removed) > > the cpu removal code would also attempt to migrate user process to another cpu, > retarget interrupts to another existing cpu etc. I havent tested the hotplug > code on sgi boxes so far. (only tested on some hp boxes by Alex Williamson > and on tiger4 boxes so far) > > Cheers, > ashok -- Michael A. Raymond Office: (651) 683-3434 Core OS Group Real-Time System Software