Date: Tue, 19 Nov 1996 18:55:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: smp@csn.net (Steve Passe) Cc: barney@databus.com, freebsd-smp@freebsd.org Subject: Re: reinventing vs copying Message-ID: <199611200155.SAA10139@phaeton.artisoft.com> In-Reply-To: <199611200135.SAA21266@clem.systemsix.com> from "Steve Passe" at Nov 19, 96 06:35:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'd like to understand better than I do (which is hardly at all) why it > > seems (to me) as though all the SMP work is being done without reference > > to what other SMP-capable OS's do. > > good question. > > --- > > I do understand that code cannot be copied, certainly from the > > commercial systems and not even from Linux without complying with the > > GPL, but what prevents the borrowing of ideas or even the discussion > > of how common problems are handled by other, seemingly working, > > implementations? > > nothing, we sometimes do. In some cases the internals of the systems > differ so greatly that what works for one won't for the other. For example, > Terry posted a rather detailed discussion of another OS's method for handling > INTs, and how it would resolve the "missing INT" problem of the IO APIC. > But the methods used are so far from the FreeBSD kernel as to be unusable > for us. More than anything it is just that we don't run in those circles. My take on this is that no one is working at the level of detail where the answer to the question matters. Mostly, the work so far falls into mapping abstractions onto the hardware for the highest possible concurrency at the lowest possible level. So far, I don't believe anyone is building scheduler changes, for instance... there are a number of research papers in scheduling ATM packets onto "leaky bucket" transports that are applicable... for instance, there is at least one nice fuzzy logic system for scheduling that would probably translate well. Good Masters thesis or PhD dissertation material. 8-). Other than me (and I'm a fanatic), I don't think anoyone else is looking at methods of increasing concurrency, at least not in any detail, in the kernel itself. Mostly, the soloutions to those problems are in the "UNIX For Modern Architectures" and the "UNIX Internals: The New Frontiers" books. Topologically, the problem is the same for RT scheduling (kernel preemption), kernel threading (kernel preemption), and processor scheduling (Processor affinity). Many people find that uninteresting... When it comes time to worry about those things, they will be worried about... pour a level foundation, and *after* that, you can build a level house. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611200155.SAA10139>