From owner-svn-src-all@FreeBSD.ORG Tue Oct 19 13:37:25 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 A53C01065679; Tue, 19 Oct 2010 13:37:25 +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 9AE278FC12; Tue, 19 Oct 2010 13:37:24 +0000 (UTC) Received: by bwz15 with SMTP id 15so228482bwz.13 for ; Tue, 19 Oct 2010 06:37:23 -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=Y+A0uN4tQc7LYBs1Wm9MWmo9oKofIGsLaeWo3+xofsY=; b=H2kltqWN6Ooj93hp/udvrfgkgk39TlLTP6O3/zqNXoe0K3Q6lqs3HEFeiZxuW4nlts KajdA0NlEbmF5uFm/RByFCXN5OUFmvE3HbfgHicCgdUpbppAHOStK7GsGgI4pt0LC0ou rNvUxaxc7ioTAZDhQ5FWgYc6RohcAa7uUJOrs= 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=XzKGBEN0qro2p3UYc7Puw6sk/8E+RklOalwSmQ9rdGXIeg9SlQJG1UPHkmTa/tPxsV 9j3dxduWF186fNBc+WygDQ8wHHLYm5SwDdff9n3JUg096FqGhFa6XTnpFCSlr+M3In3/ XdduQFBQHUGFY9du8Txri6Ik5II1WVWgPlMIg= Received: by 10.204.42.4 with SMTP id q4mr2587542bke.47.1287495442996; Tue, 19 Oct 2010 06:37:22 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id g8sm13153303bkg.11.2010.10.19.06.37.19 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Oct 2010 06:37:20 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CBD9F0B.80701@FreeBSD.org> Date: Tue, 19 Oct 2010 16:37:15 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: John Baldwin References: <201010171646.o9HGks2U038501@svn.freebsd.org> <20101018213055.GP1416@alchemy.franken.de> <4CBCBF25.8010902@FreeBSD.org> <201010190836.37272.jhb@freebsd.org> In-Reply-To: <201010190836.37272.jhb@freebsd.org> 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, Marius Strobl 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: Tue, 19 Oct 2010 13:37:25 -0000 John Baldwin wrote: > On Monday, October 18, 2010 5:41:57 pm Alexander Motin wrote: >> 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. > > I don't see why the interrupt frame logic requires bumping > td_intr_nesting_level. It doesn't. It was two different sentences. I've just noticed that td_intr_nesting_level used by SCHED_ULE to bind interrupt threads on their CPUs. I agree that it may be not a very good idea, but it is what we have now. -- Alexander Motin