From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 03:59:55 2004 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 AB5E616A4D0 for ; Fri, 12 Nov 2004 03:59:55 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2045D43D31 for ; Fri, 12 Nov 2004 03:59:55 +0000 (GMT) (envelope-from anurekh@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so391003rns for ; Thu, 11 Nov 2004 19:59:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RqxAC+neNcabNVmkS+ttJQVRomX8wy69zj51ZvlJmtAbTvKd/TYjogf9Vpg/GtGY1QzBJewUHfRklrd4fRnCGaZct2wbqHUHPAFQAPW4xR+F2b5Rgey2O+sxokO3ihzRUH2B8RfeJwLFealDDBWm6m4BBHyHSPNQ8K+dMFiDSjI= Received: by 10.38.206.73 with SMTP id d73mr739338rng; Thu, 11 Nov 2004 19:59:54 -0800 (PST) Received: by 10.38.8.23 with HTTP; Thu, 11 Nov 2004 19:59:54 -0800 (PST) Message-ID: Date: Thu, 11 Nov 2004 22:59:54 -0500 From: Anurekh Saxena To: Robert Watson In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: cc: freebsd-current@freebsd.org Subject: Re: kernel: return from interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Anurekh Saxena List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 03:59:55 -0000 > > > Even normal "options PREEMPTION" should do this. I know from tracing the > > > kernel in 6.x that that's the way the system behaves out of the box; with > > > PREEMPTION turned on in 5.x you should see the same behavior. One thing I > > > often do see, FWIW, is that if you're on an SMP box, the ithread will get > > > scheduled to run immediately on another CPU that's idle, so you won't > > > actually preempt the thread on the current CPU other than for the > > > interrupt handler. What behavior are you seeing that suggests this isn't > > > happening with PREEMPTION compiled in? > > > > I may be missing something fundamental here, but, doreti (exceptions.s) > > does not call 'ast' for an interrupted task, that does not have RPL of 3 > > (user). So, even if an interrupt is pending, and the 'NEEDRESCHED' is > > set, the scheduling decision is delayed till the kernel thread or > > whatever was running in the kernel sleeps, or give up the cpu(call > > mi_switch), or returns to user mode. > > > > AFAIK this is the only return path from an interrupt. Unless there is > > another return path for the interrupts, the scheduler is not invoked on > > a return. > > Assuming we're talking about i386, lapic_handle_intr() will call > intr_execute_handlers(), which will walk the list of handlers for the > interrupt, and either directly invoke the fast handlers of the interrupts, > or call ithread_schedule() to schedule the ithread. ithread_schedule() > will invoke setrunqueue(), which enters the scheduler and is a preemption > point. If you dig down a bit, you'll find a call to maybe_preempt(), > which may preempt if appropriate, resulting in a call to mi_switch() to > the ithread. The maybe_preempt() code will only kick in to actually > switch if PREEMPTION is defined. Yeah, I got it wrong. Without the FULL_PREEMPTION enabled, it does not preempt unless the current thread is in the idle priority band. I was expecting the NEEDRESCHED flag to be used for preemption on return paths, especially for interrupt context. I think this method works better since preemption points become well defined in the kernel. Thanks for helping me figure this out. -Anurekh