Date: Wed, 24 May 2000 20:05:25 -0600 From: Chuck Paterson <cp@bsdi.com> To: Terry Lambert <tlambert@primenet.com> Cc: arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005250205.UAA16126@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
} }Jeffrey Hsu recently commented on this to me in regards to a paper }by Michael Greenwald, in regard to having lock-free synchronized }lists in the kernel. } If you do this in MI code you also have to have primitives to handle the relaxed memory model on machines like Sparc. } }It would be interesting to know why the cycle counter was required, }and how BSDI would deal with this on SMP Alpha and SPARC machines, }or the new IBM 64 PPC processor NUMA machines... } It is not actually required, it is just better, and therefore one more differnce. The cycle counter is used for a couple of things. One is a very fast tracing facility, the other is microtime. On sparc there is a cycle counter for the tracing but I believe BSD/OS falls back to the standard clock stuff for microtime. This stuff is all in MD code. } }You can buy external APICs for 486 based systems to achieve 486 }SMP. This is where Intel SMP came from in the first place. The }APICs went into the processor proper more to thwart third party }processor manufacturers from creating SMP boxes using Intel APIC }chips but not CPU chips, than anything else. } My understanding is that the external apics have a different programming model and are no fun to deal with. Seems like something someone could do at anytime if they had a few months to kill. } }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. } }Supporting loading of more segments, with segment attributes, is an }obvious approach; Microsoft does this with VxD's and other NT and }Windows kernel components, today. The only thing you have to worry }about is being able to serialize access to the section being replaced }(only during the replacement process) and not be in it when you flip }the page table entry. You could even do defragmentation of the kernel }address space, if you thought is was more useful than running on the }new code and copying the new code to the old location, and then }running there instead. } } } Terry Lambert } terry@lambert.org }--- First let me say that I purposely picked the proposal I did because some people said it was a possibility and it needed to get accepted or put to rest. I think we know the answer to that The work doing two kernels is no in chosing the one to run, but getting the low level primitives and interrupt code working across all the desired platforms. I would assert this is not trivial, but not a big deal either. The problem I see with Windows thing you mention above is that every module will change. If you want to go fast the mutex operations are going to be inlined. This means that there isn't like one piece you can just replace. 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?200005250205.UAA16126>