Date: Thu, 05 Sep 2002 18:48:59 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-alpha@FreeBSD.ORG Subject: Re: ithread preemption Message-ID: <3D78098B.CEBF13EC@mindspring.com> References: <XFMail.20020905163105.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > Hey ... I think you have it on the nose! That makes the most sense > > I've heard yet. > > > > Do we have any way to bind a thread to a cpu? > > I used to. Then KSE3 was committed. I suppose I could rewrite it from > scratch again. The ithreads are different from threads. People don't seem to get this idea, but it is nevertheless true. The x86 SMP doesn't have this problem (yet), in that the IRQ is disabled on the I/O APIC, so it doesn't matter what CPU it runs on, it's a seperate thing. If x86 NUMA systems are ever supported, or in some cases the AMD Alpha-derived arbitration is used, there could be a problem (but not for the same reasons as on the Alpha). Using all the same primitives for ithreads as for threads will lead to things like a shared IRQ which comes true for multiple devices will need to count down to enable, if the ithreads for servicing are run simultaneously on seperate CPUs. This also implies a global lock on enabling a newly arrived device that's sharing an already allocated IRQ, and inter-CPU contnetion on any IRQ whose use cont is != 1. Interrupt threads make some very messy thing elegant, but they do so at the cost of moving the mess elsewhere. If you have to characterize it, call it "The law of conservation of inelegance". 8-). The only thing that ever saves you from it is a top-down design. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D78098B.CEBF13EC>