Date: Tue, 3 Mar 1998 03:08:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tom@uniserve.com (Tom) Cc: toor@dyson.iquest.net, tlambert@primenet.com, smp@csn.net, opsys@mail.webspan.net, jak@cetlink.net, current@FreeBSD.ORG Subject: Re: 3.0-RELEASE? Message-ID: <199803030308.UAA10469@usr06.primenet.com> In-Reply-To: <Pine.BSF.3.96.980302174740.6855E-100000@shell.uniserve.com> from "Tom" at Mar 2, 98 05:49:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, think of it like this: > > 3.0 simple SMP. > > 3.1 much better SMP. > > How is it that Linux has moved so much faster in this area? Or have > they? I like Jordan's answer, but the truth is, there is very little effective difference in implementations. SMP concurrency is a mathematically hard problem. It will need a lot of serious, mind-numbing detail work to get right. Probably several people will have their minds numbed in the process, and the one with the numbest mind will be the implementation chosen because it will have the best performance. I *don't* believe that Linux has solved this problem in a general sense; it requires a lot of academic rigor, and that's in short supply in volunteer projects (Eric Raymond's paper not to the contrary). > It seems to me that they even have kernel threading too, although it > seems to me that their threads are a bit heavy (almost pseudo-processes). They are. AFAIK, they do not have an affinity model. Kernel threading is, IMO, not a win at all, unless you combine it with a cooperative user space scheduler, or implement it using call contexts so you can keep your quantum, or throw the threads at a sufficiently large number of CPU's to overcome the non-affinity L1 cache and relative scheduling losses from competing with other processes and threads for quantum (this is what makes the context switch wins go away, but makes your benchmarks look nice on idle systems). I think user space threading is vastly misunderstood and vastly underrated. There is a big difference between call-conversion based yielding and explicit yielding. Most comparisons I have seen are based on the idea that the two are equivalent, or that you can't implement fairness in the case where a bad programmer fails to write code that doesn't buzz-loop (buzz-looping is a bad thing in the general sense of codeing in a single process; it is moreso in the sense of threads). The one real drawback is that you can not compete as more than 1 process for quantum; this is a scheduler issue. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199803030308.UAA10469>