From owner-freebsd-current@FreeBSD.ORG Mon Nov 15 22:46:05 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 56FEC16A4D0 for ; Mon, 15 Nov 2004 22:46:05 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id B10E343D41 for ; Mon, 15 Nov 2004 22:46:04 +0000 (GMT) (envelope-from anurekh@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so539882rns for ; Mon, 15 Nov 2004 14:46:04 -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=I8qsnUlcWqKbL86v/kA31AQmn4T7DA9vXBoxczT51TPfuu52T23fT8wiCzxGwBTmaj+TQtABxDsMJ2xa1U77y1SnySPs7RlRBTvHoDRbWUKB90VrVFy6bebrF904usUaxJ1ejiThRxCV85B+TKm51EHvd4PAYWWtsThYt53+Mko= Received: by 10.38.179.67 with SMTP id b67mr1221831rnf; Mon, 15 Nov 2004 14:46:03 -0800 (PST) Received: by 10.38.8.23 with HTTP; Mon, 15 Nov 2004 14:46:03 -0800 (PST) Message-ID: Date: Mon, 15 Nov 2004 17:46:03 -0500 From: Anurekh Saxena To: John Baldwin In-Reply-To: <200411151433.57236.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200411151433.57236.jhb@FreeBSD.org> cc: freebsd-current@freebsd.org cc: Robert Watson 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: Mon, 15 Nov 2004 22:46:05 -0000 On Mon, 15 Nov 2004 14:33:57 -0500, John Baldwin wrote: > On Thursday 11 November 2004 10:59 pm, Anurekh Saxena wrote: > > > > > > > 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. > > NEEDRESCHED (albeit rather broken at the moment) is used to implement > preemptino of user threads. As Robert mentioned above, in-kernel preemption > is managed via either direct switches in setrunqueue() or deferred > preemptions via TDF_OWEPREEMPT in critical_exit(). > Yeah, I think I get the way its done, but it would be nice to be able to use the NEEDRESCHED flag as a general way to say... we need to resched, irrespective of which mode we are returning to. I don't know how much of the code expecrs the current behavior. I can think of atleast two ways in which the generic flag could be used. I don't know whether its a good idea or not. Just a thought. 1> The generic return-from-'some form of interrupt' path can simply call the scheduler if the flag is set. Though I cant think of any examples to provide, but it may be used as a defer flag, just like the TDF_OWEPREEMPT is used at the moment. 2> A kernel thread that wants to be able to do as much work as it can, may keep checking this flag and know when to preempt. Thanks, -Anurekh