From owner-svn-src-all@FreeBSD.ORG Mon Oct 18 21:42:03 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93246106566C; Mon, 18 Oct 2010 21:42:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 876078FC0C; Mon, 18 Oct 2010 21:42:02 +0000 (UTC) Received: by bwz16 with SMTP id 16so119770bwz.13 for ; Mon, 18 Oct 2010 14:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=SIZ9/1T45x08RYa6bz/6I0uEbZL+HUn4mKfgOmWlNAE=; b=JRbrbRzDRVtsaJzXS/m5o6tGSxZqwFvZWpDpOiILxeQq1NL9rmfR/hRdm0L3Jzu2Lm NEejN+3lvUMjYkYGxY6OFdkWoujQ8QAXSwUYiu0AZu3zfaa/oCCeTFu3kgSuHUwdrJ0C 6JbTRZGjRcvFHc8/4evSVI3Rxz8b/4wsxC3F8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=CefEWW0fdcQEf9ABhuauE57qXBRqdUbaENNhKaD/Ojy4cBoqrew5Le9kAtl6xwItIa RxYpq9NnrfMUYbcQe1rnDRpwSF4GJVYDWfForJyzCPpkhinvoCftEnDkJ4W5l/WkufsW d/LUV/cmLmXhDUURioKqoS222JOJiw9FFvGOY= Received: by 10.204.46.226 with SMTP id k34mr4843952bkf.38.1287438121212; Mon, 18 Oct 2010 14:42:01 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm14545460bki.1.2010.10.18.14.41.59 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Oct 2010 14:42:00 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CBCBF25.8010902@FreeBSD.org> Date: Tue, 19 Oct 2010 00:41:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Marius Strobl References: <201010171646.o9HGks2U038501@svn.freebsd.org> <4CBCADDD.5070109@FreeBSD.org> <20101018205224.GO1416@alchemy.franken.de> <201010181705.24879.jhb@freebsd.org> <20101018213055.GP1416@alchemy.franken.de> In-Reply-To: <20101018213055.GP1416@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin Subject: Re: svn commit: r213985 - head/sys/sparc64/sparc64 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 21:42:03 -0000 Marius Strobl wrote: > On Mon, Oct 18, 2010 at 05:05:24PM -0400, John Baldwin wrote: >> On Monday, October 18, 2010 4:52:24 pm Marius Strobl wrote: >>> AFAICT this is not true; intr_event_handle() in sys/kern/kern_intr.c >>> is what enters a critical section and f.e. on amd64 I don't see where >>> anywhere in the path from ISR_VEC() to intr_execute_handlers() >>> calling intr_event_handle() a critical section would be entered, >>> which also means that in intr_execute_handlers() td_intr_nesting_level >>> is incremented outside of a critical section. >> Not all of the clock interrupts use intr_event_handle(). The local APIC >> timer uses its own interrupt entry point on x86 for example and uses an >> explicit critical section as a result. I suspect the sparc64 tick interrupt >> is closer to the local APIC timer case and doesn't use intr_event_handle(). > > Correct; but still you can't say that the MD interrupt code enters a > critical section in general, neither is incrementing td_intr_nesting_level > in intr_execute_handlers() protected by a critical section. > >> The fact that some clock interrupts do use intr_event_handle() (e.g. the >> atrtc driver on x86 now) does indicate that the low-level interrupt code >> probably does not belong in the time events code but in the caller. > > Well, I agree that entering a critical section in the time events > code would mean entering a nested critical section unnecessarily in > case the clock driver uses a regular "fast" interrupt handler and > that should be avoided. Still I don't think the event time front-end > actually should need to worry about wrapping the callback in a > critical section. Interrupt frame, required for hard-/stat-/profclock() operation is stored in curthread. So critical section is effectively mandatory there now. Correct td_intr_nesting_level value is also important for proper interrupt threads scheduling - one more reason to have critical section there. It is indeed strange that td_intr_nesting_level in intr_event_handle() is not covered by critical section, but probably it should. -- Alexander Motin