From owner-freebsd-current Sun Feb 24 23:13:10 2002 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 36A4237B404; Sun, 24 Feb 2002 23:13:05 -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 SAA25994; Mon, 25 Feb 2002 18:12:56 +1100 Date: Mon, 25 Feb 2002 18:13:17 +1100 (EST) From: Bruce Evans X-X-Sender: To: Matthew Dillon Cc: Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , , John Baldwin Subject: Re: Success! critical_enter()/critical_exit() revamp (was Re: malloc_bucket() idea (was Re: How to fix malloc.)) In-Reply-To: <200202250152.g1P1q1d27292@apollo.backplane.com> Message-ID: <20020225180234.C39518-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 24 Feb 2002, Matthew Dillon wrote: > :cpu_switch() certainly needs to do this if it can be called with the > :interrupt enable flag[s] in different states. I need the sti's (actually > :enable_intr()'s because I don't want fast interrupts to be disabled > :during context switches. This works because enabling interrupts is sure > :to be safe, since we might be switching to a thread that will enable > :them. Some sort of lock is needed to prevent interrupts interfering > :with the switch. I think soft-masking them in critical_enter() is > :sufficient in your version too. > > I don't think we want to make sched_lock any more complex then it > already is, so at least for the foreseeable future we are not > going to be able to actually execute an interrupt handler until > the sched_lock is released in (typically) msleep(). I am rather Well, my kernel has been executing fast interrupt handlers while sched_lock is held for almost a year. It's actually less complicated with respect to sched_lock but more complicated with respect to fast interrupt handlers. > annoyed that two levels of procedure have to be called with the > sched_lock held (mi_switch() and cpu_switch()), leaving interrupts > disabled for a fairly long period of time, but I don't see any way > around it right now. The worst offenders for interrupt latency seemed to be calcru() and/or the sched_locking related to fork and/or exit. Latency was many thousand instructions (reasonable only on 100+ MIPS machines). sched_locking for calcru() is moostly bogus and should be easy to avoid, but not so for context switching. > Eventually (presumably) we will have per-cpu run queues. That combined > with interrupt stealing may resolve the problem for us. I am still > not convinced that making the various *pending* flags globals will > be more efficient, because it introduces significant cache mastership > issues. It might be easier to do this: OK. I don't care about this yet. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message