> > > 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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |