jkrueger@daitc.daitc.mil (Jonathan Krueger) (03/12/89)
In article <328@akelei.UUCP>, dwight@akelei (Dwight Melcher) writes: >It seems that DBMS's put pressure on UNIX facilities that make >UNIX developers think about adding new, more flexible, kernel >facilities. This might work to a point, but I would hate to see the >seething mass of UNIX kernel necessary to provide all the flexibility >that is needed. DBMS's provide a strong case for providing a tiny >kernel and a *standard framework for adding new facilities to an >existing kernel*. This way, a DBMS can have more control over system >resources, policies, etc. independent of whatever policies are provided >for typical edit-compile-run type multiuser environments. I think >CMU's MACH takes a stab at trying to provide this sort of thing, but I >haven't looked at it closely enough to make any comments on it. DBMS's do, multiprocessors do, networks do, even interesting devices do. And these are exactly the problems Mach is designed to address. >And don't forget: > > * Control over page replacement policies > >Presumably, pages mapped in with mmap are still subject to the OS's >default page replacement policies. LRU page replacement seems to be a >particularly widespread policy used for both OS filesystems and virtual >memory systems. Mach takes memory mgmt out of the kernel. The Mach user can specify a different memory mgr just as he specifies his shell in Unix. Or perhaps a more compelling analogy would be that the Mach user can tune application performance by selecting a different memory mgr just as the database programmer can tune database application performance by choosing a different storage structures and access methods. However you look at it, the important aspects are transparency and generality. Programs should continue to run correctly under all conditions. And as many types of programs as possible should be able to obtain this transparent speedup. The Mach approach appears to offer this. -- Jon --