Date: Sat, 23 Feb 2002 19:30:24 -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: malloc_bucket() idea (was Re: How to fix malloc.) Message-ID: <200202240330.g1O3UO189713@apollo.backplane.com> References: <20020224131027.I31343-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :(the ICU masks pending interrupts).
:> :
:> :Bruce
:>
:> Ok, I have most of it coded up. Could you explain what 'spending'
:> was for?
:
:Like the SWI bits in ipending in RELENG_4. In RELENG_4, we have to pass
:around all the bits to spl*(), so we had to pack them in at least some
:places (not required in inpending, but efficient). In -current, packing
:is not so important even if it is possible, so I didn't attempt it.
:
:> I am doing it slightly different then you. To avoid having to use
:> locked instructions I have placed ipending in the thread structure:
:
:Mine is global partly for historical reasons. BTW, I've found that
:variables in the thread struct are more fragile than per-cpu globals.
:You have to remember to deal with them all before you switch threads.
:I needed to clone td_critnest to the next thread in one or two places
:(at least one related to the complications for forking).
Ah, task switching... that's a stickymess. In that case, I think placing
it in a per-cpu variable is the correct solution. I can still avoid the
locked bus cycle.
I dealt with the fork issue by having the trampoline code setup
td_critnest before doing to the sti, since it is far too late to
setup critnest in fork_exit.
:> OR the irq bit into td->td_ipending (it conveniently already has
:> the struct thread in %ebx). And the vector code will also check and
:
:I do this at the start of sched_ithd(). This is efficient enough because
:the nested case is rare.
Yup, same here.
:> handle any non-zero td_ipending if critnest is 0, handling the
:> 1->0 transition/preemption race.
:>
:> I'll post the patch when it gets a little further along.
:>
:> How should I deal with fast interrupts?
:
:Hmm, this gets complicated. First, you need the td_critnest test
:in Xfastintr* (do it before Xfastintr* calls critical_enter()). It is
:important in -current (although bad for latency) that critical_enter()
:keeps masking even fast interupts although it doesn't do it in software).
:Next, you need to mask the fast interrupt. It probably needs to be
:masked in the ICU/APIC on i386's, so it will become not-so-fast. Finally,
:unpend() needs to do more for fast interrupts:
:- give them highest priority
:- unmask the in the ICU/APIC/wherever, either before or after calling the
: handler.
:
:Bruce
This is fairly straightforward. I will give the per-cpu area a
separate pending variable for fast interrupts and maybe a master
'some kind of interrupt is pending' flag for critical_exit() to
test.
-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?200202240330.g1O3UO189713>