Date: Thu, 20 Jun 2002 21:31:32 -0600 From: Chuck Paterson <cp@twistedbit.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <200206210331.g5L3VWw26582@grendel.twistedbit.com> In-Reply-To: Your message of "Thu, 20 Jun 2002 22:07:12 CDT." <20020620220712.E70387@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just a couple of random notes: The cut of BSD/OS that was handed off to FreeBSD didn't have multiple theads running networks interrupts because there were still these globals used by the tcp stack. With interrupts typically borrowing the context that was in place, BDS/OS on return from the hardware interrupt would typically run the the software interrupt on the same processor as the hardware interrupt. There typically was not a cpu switch type scheduling event. BSD/OS used a thread per interrupt to allow interrupt of higher priority to nest as much as to have multiples hardware interrupts running at a time. We though per cpu run queues were a great idea at BSDI. We didn't do them because we had lots of other stuff to do, and we really had not come up with a good answer to the when do you migrate a process question. How long do you want to let a cpu be idle before you move something on to it? But mainly it was we had lots of other stuff to do first. It seems like the number of threads you want running the network stack is depends upon what your work load is. It doesn't seem like a one answer fits all problem, at least to me. On a dual processor system running 75% user and 25% system it seems like a bad idea to use two processors in the kernel. You don't need the horse power, and you'll likely pick up some lock and cache line contention. Now if you 2 hyper threaded cpus then maybe it would be better to use two of them on the network stack, and two in userland. If you allow two cpus to process packets from the same tcp stream you can end up with packets passing each other. While this isn't suppose to be fatal, lots of stuff doesn't handle it well or at all. Later Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206210331.g5L3VWw26582>