From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 22:08:47 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 93FA916A4D0 for ; Thu, 11 Nov 2004 22:08:47 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262DE43D1D for ; Thu, 11 Nov 2004 22:08:47 +0000 (GMT) (envelope-from anurekh@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so378162rns for ; Thu, 11 Nov 2004 14:08:46 -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=pqpKUfyjjBeB8ox2xr3SpmIWy/d8ItQ+h0PlSDLP9ohBZEd3NkBglOd6Orl4Jf0dsJqJL8wIa0Nhi/7bMC4B+GONv5cDySprBSdutqBWG/nkGC7I9UNn1JtDvLCmx33wQGTDR8Cs5fLpLOr+MpKyTuDJ66AvqYOdoti5citemGw= Received: by 10.38.206.26 with SMTP id d26mr410228rng; Thu, 11 Nov 2004 14:08:45 -0800 (PST) Received: by 10.38.8.23 with HTTP; Thu, 11 Nov 2004 14:08:45 -0800 (PST) Message-ID: Date: Thu, 11 Nov 2004 17:08:45 -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: Thu, 11 Nov 2004 22:08:47 -0000 > > I was under the impression that the 5.3 release had an option for full > > preemption. If I am correct, why does the kernel refuse to schedule on > > a return_from_interrupt if its not going back to userland? I can > > understand this being a problem if interrupts were nested, or return > > from a page fault in a critical section. Please correct me if I am > > wrong, but if a *high* priority interrupt thread is ready to run, it > > should be given a chance. Presuming the *interrupted* kernel path is > > going to give up the CPU fast enough is probably not a good idea. > > > > I hope I have sent this to the right mailing list. > > 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. Thanks, -Anurekh > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > >