From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 18:30:08 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 7F8FB16A4CE for ; Thu, 11 Nov 2004 18:30:08 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09F7D43D45 for ; Thu, 11 Nov 2004 18:30:08 +0000 (GMT) (envelope-from anurekh@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so365448rns for ; Thu, 11 Nov 2004 10:30:07 -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:mime-version:content-type:content-transfer-encoding; b=kIRdtSfJxaLsZcfpHc5bufAcqb5RorIa6KJ6XVdPzqi6ehw3Ha1M4eg4jLAs1fD55zjHGq8lGwsrY2DbzuCur12x8bquzYoZ2Ev9smE9mekFzXz08ZCnNq2+3X9RkPPzc6Rlkk2UvJ4ilbtbIPJhkDASZzbr76K97IYyvYTrSNE= Received: by 10.38.206.26 with SMTP id d26mr316133rng; Thu, 11 Nov 2004 10:30:07 -0800 (PST) Received: by 10.38.8.23 with HTTP; Thu, 11 Nov 2004 10:30:07 -0800 (PST) Message-ID: Date: Thu, 11 Nov 2004 13:30:07 -0500 From: Anurekh Saxena To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: 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 18:30:08 -0000 Hi, 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. Thanks, Anurekh