From owner-freebsd-current Mon Feb 25 0:22:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 84D6637B41A; Mon, 25 Feb 2002 00:22:45 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1P8Mes47223; Mon, 25 Feb 2002 00:22:40 -0800 (PST) (envelope-from dillon) Date: Mon, 25 Feb 2002 00:22:40 -0800 (PST) From: Matthew Dillon Message-Id: <200202250822.g1P8Mes47223@apollo.backplane.com> To: Bruce Evans 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.)) References: <20020225180234.C39518-100000@gamplex.bde.org> 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 :> 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. :... :Bruce Yah, that's a fairly nasty routine. sched_lock is being used as an interlock even more then it is being used to cover scheduler queueing operations. I think the direction I would take would be to try to address sched_lock's use rather then try to special case interrupts. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message