From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752317AbXBGCe1 (ORCPT ); Tue, 6 Feb 2007 21:34:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965273AbXBGCe1 (ORCPT ); Tue, 6 Feb 2007 21:34:27 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:52417 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbXBGCe0 (ORCPT ); Tue, 6 Feb 2007 21:34:26 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Ingo Molnar Cc: Andrew Morton , linux-kernel@vger.kernel.org, "Lu, Yinghai" , Luigi Genoni , Natalie Protasevich , Andi Kleen Subject: Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration. References: <200701221116.13154.luigi.genoni@pirelli.com> <200702021848.55921.luigi.genoni@pirelli.com> <200702021905.39922.luigi.genoni@pirelli.com> <20070206073616.GA15016@elte.hu> <20070206222523.GA11602@elte.hu> Date: Tue, 06 Feb 2007 19:33:10 -0700 In-Reply-To: <20070206222523.GA11602@elte.hu> (Ingo Molnar's message of "Tue, 6 Feb 2007 23:25:23 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar writes: > * Eric W. Biederman wrote: > >> Ingo would it be reasonable to get a wait queue so I can wait for an >> irq that needs the delayed disable action to actually become masked? > > that might make sense, but what will do the wakeup - incidental IRQ > arriving on the new CPU? That is what I was thinking. > Isnt that a bit risky - maybe the device wont > generate IRQs for a really long time. Well this is in a user space context called from user space and it exactly matches the semantics we have now. If we make it an interruptible sleep the user space process shouldn't block. I guess the other thing to do is do it in a non-block fashion and just call schedule_work from the interrupt context when the irq is disabled. For i386 with it's in kernel irq scheduler that might be better. I think the nasty case is probably what do we do when it is the timer interrupt we are dealing with. Hmm. I think I should look up what the rules are for calling local_irq_enable when in interrupt context. That might be another way to satisfy this problem. If local irqs are enabled I don't have to worry about the irr register. You've got me brainstorming now. Eric