From owner-freebsd-current Sat Feb 23 18:55:23 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 2AD8437B402; Sat, 23 Feb 2002 18:55:18 -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 NAA06661; Sun, 24 Feb 2002 13:55:10 +1100 Date: Sun, 24 Feb 2002 13:55:27 +1100 (EST) From: Bruce Evans X-X-Sender: To: Matthew Dillon Cc: Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , , John Baldwin Subject: Re: malloc_bucket() idea (was Re: How to fix malloc.) In-Reply-To: <200202240154.g1O1suv36741@apollo.backplane.com> Message-ID: <20020224131027.I31343-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 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