Date: Mon, 25 Feb 2002 00:22:40 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au> Cc: Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, <current@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG> Subject: Re: Success! critical_enter()/critical_exit() revamp (was Re: malloc_bucket() idea (was Re: How to fix malloc.)) Message-ID: <200202250822.g1P8Mes47223@apollo.backplane.com> References: <20020225180234.C39518-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202250822.g1P8Mes47223>