> > > the fast path slower and less maintainable. if you are really concerned > > > about isolating many competing servers on a single piece of hardware, then > > > run separate virtualized environments, each with its own user-space. > > > > And the virtualisation layer has to do the same job with less > > information. That to me implies that the virtualisation case is likely > > to be materially less efficient, its just the inefficiency you are > > worried about is hidden in a different pieces of code.
I imagine you, like me, are currently sitting in the Xen talk, and I don't believe they are or will do anything so dumb as to throw away or lose information. yes, in principle, the logic will need to be somewhere, and I'm suggesting that the virtualization logic should be in VMM-only code so it has literally zero effect on host-native processes. *or* the host-native fast-path. > > Secondly a lot of this doesnt matter if CKRM=n compiles to no code > > anyway > > I'm actually trying to keep the impact of CKRM=y to near-zero, ergo > only an impact if you create classes. And even then, the goal is to > keep that impact pretty small as well. but to really do CKRM, you are going to want quite extensive interaction with the scheduler, VM page replacement policies, etc. all incredibly performance-sensitive areas. actually, let me also say that CKRM is on a continuum that includes current (global) /proc tuning for various subsystems, ulimits, and at the other end, Xen/VMM's. it's conceivable that CKRM could wind up being useful and fast enough to subsume the current global and per-proc tunables. after all, there are MANY places where the kernel tries to maintain some sort of context to allow it to tune/throttle/readahead based on some process-linked context. "embracing and extending" those could make CKRM attractive to people outside the mainframe market. > Plus you won't have to manage each operating system instance which > can grow into a pain under virtualization. But I still maintain that > both have their place. CKRM may have its place in an externally-maintained patch ;) regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
