From owner-freebsd-current Fri Feb 9 10:26:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 665C137B4EC for ; Fri, 9 Feb 2001 10:26:10 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA31083; Sat, 10 Feb 2001 05:26:02 +1100 Date: Sat, 10 Feb 2001 05:25:40 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alexander Leidinger Cc: current@FreeBSD.ORG Subject: Re: kernel trap 12 with interrupts disabled In-Reply-To: <200102091305.f19D52T02449@Magelan.Leidinger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Feb 2001, Alexander Leidinger wrote: > On 9 Feb, Bruce Evans wrote: > > > Pagefaults occur in copyin() (called from addupc_task() which is called > > from ast()) while sched_lock is held. This is not good. Incrementing > > the profiling counters is supposed to be pushed to ordinary process > > context so that things like copyin() can work (they have to be able > > to fault in pages, so they have to be able to sleep...), so using > > sched_lock to lock things here is wrong. > > Are we talking about /sys/kern/kern_clock.c: statclock()? I'm not No :-). ast() is in /sys/${MACHINE}/${MACHINE}/trap.c. Incrementing the profiling counters is much too hard to do in statclock(), since statclock() is a fast interrupt handler, so statclock() only schedules an AST to do the increment. The scheduling of the AST is rather tangled and pessimized to support optimizations that aren't possible while statclock() is a fast interrupt handler. See addupc_intr(), fuswintr(), suswintr() and need_proftick(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message