Date: Wed, 24 May 2000 19:13:10 -0700 From: Mike Smith <msmith@freebsd.org> To: Terry Lambert <tlambert@primenet.com> Cc: arch@FreeBSD.ORG Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005250213.TAA03797@mass.cdrom.com> In-Reply-To: Your message of "Thu, 25 May 2000 01:48:57 -0000." <200005250148.SAA12472@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I think the work required to build two kernels instead of one, and > > > then CPU-testing in the loader to pick one, is really trivial. I > > > think there are better approaches to the problem than this, but > > > this is enough to throw out that idea entirely. > > > > Are the mutexes inlined, or are they all function calls? If the latter, > > loading lock_smp.ko vs. lock_std.ko would be pretty trivial... 8) > > I expect that they are inlined. This would actually be a fairly Bad Thing on at least some platforms. Maybe we should consider whether they should be inlined on some and function calls on others (where there might be separate implementations). Function call overhead on i386 is pretty low... On eg. Sparc where there's only likely to be one implementation, we don't need the ability to switch them around, and thus they could be inlined. > You could also tag functions that used these things to go into a > seperate section, and then load "586_critical_sections.ko" instead, > which would also be pretty trivial. That'd make for some pretty damn ugly modules/drivers. > One I've been evilly considering is that the older processors > lacking the instruction could simply take an instruction fault, This would only make sense if the fault handler patched the offending code; it'd be too expensive otherwise. I don't think this'd work on i386, since the replacement code sequence is larger... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com 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?200005250213.TAA03797>