Date: Tue, 30 Nov 1999 14:25:55 -0800 From: Jason Evans <jasone@canonware.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991130142555.F301@sturm.canonware.com> In-Reply-To: <199911280338.TAA40637@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Nov 27, 1999 at 07:38:52PM -0800 References: <Pine.SUN.3.91.991124134533.26314A-100000@pcnet1.pcnet.com> <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 27, 1999 at 07:38:52PM -0800, Matthew Dillon wrote: > :Until reading about DEC's threading efforts > :(http://www.digital.com/info/DTJF03/DTJF03SC.TXT) a few days ago, I would > :have agreed with you. However, that paper makes some very valid arguments > :for needing multiple scheduling queues. The paper is very worthwhile > :reading. > : > :Jason > > hmm. A very interesting article. They could well be correct - certainly > a single scheduling queue would become a problem if you have many > processors. I don't think there would be much contention with 4-8 cpu's, > at least not if we limit the lock to *just* the operation surrounding > the addition and removal of the KSE (using Julian's terminology) from > the queue. Also, this contention would *not* occur during a context > switch, only when a task is scheduled and descheduled. It seems to me that there would be some significant negative impacts due to cache sloshing, since all CPUs would need to modify the same scheduling queue often enough for it to be a big deal. I agree that the lock contention would be insignificant, but the caching issues seem real. Maybe I don't completely understand what you're proposing. > Another possible solution to the single-queue case is to not lock the > queue for sleep/wakeup operations but to instead shared-lock the > surrounding task(s). This would allow multiple cpu's to add and remove > tasks from different parts of a single queue simultaniously. I've > never done this myself -- it's never seemed worthwhile. Hmm, this idea could have some merit. We should keep it in mind. Jason 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?19991130142555.F301>