Date: Sun, 24 Feb 2002 13:55:27 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Dillon <dillon@apollo.backplane.com> 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: <20020224131027.I31343-100000@gamplex.bde.org> In-Reply-To: <200202240154.g1O1suv36741@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Feb 2002, Matthew Dillon wrote:
> :ipending here works much as in RELENG_4. It is ORed into by sched_ithd()
> :if curthread->td_critnest != 0. Nothing special is needed for pci
> :(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).
>
> void
> critical_enter(void)
> {
> struct thread *td = curthread;
> ++td->td_critnest;
> }
>
> void
> critical_exit(void)
> {
> struct thread *td = curthread;
> KASSERT(td->td_critnest > 0, ("bad td_critnest value!"));
> if (--td->td_critnest == 0) {
> if (td->td_ipending)
> unpend();
> }
> }
>
> The apic and icu vector code will do a simple td_critnest test and
> 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.
> 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
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?20020224131027.I31343-100000>