Messages in this thread | | | Date | Tue, 2 Jun 2009 15:51:32 -0400 | From | Chris Mason <> | Subject | Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels |
| |
On Tue, Jun 02, 2009 at 09:14:23PM +0200, Thomas Gleixner wrote: > On Tue, 2 Jun 2009, Chris Mason wrote: > > I'm not suggesting we should take broken code, or that we should lower > > standards just for xen. But, expecting the xen developers to fix the 1% > > hit on a very specific micro-benchmark is not a way to promote new > > projects for the kernel, and it isn't a good way to convince people to > > do continued development in mainline instead of in private trees. > > > > Please reconsider. Keeping these patches out is only making it harder > > on the people that want to make them better. > > You are missing one subtle point. >
I'm sure I'm missing many more than one ;)
> I read several times, that A, B and C can not be changed design wise > to allow newer kernels to run on older hypervisors. That's what > frightens me: > > dom0 imposes a kind of ABI which we can not change anymore. > > So where is the room for the improvements which you expect when dom0 > is merged ? It's not about micro benchmark results, it's about the > inability to fix the existing design decisions in the near future. > > You can change the internals of btrfs as often as you want, but you > can not change the on disk layout at will. And while you can invent > btrfs2 w/o any impact aside of grumpy users and a couple of thousand > lines self contained code, dom0v2 would just add a different layer of > intrusiveness into the x86 code base w/o removing the existing one.
Well, if there's a line we want to draw in the sand based on firm and debatable criteria, great.
The problem I see here is that our line in the sand for the xen developers is fuzzy and winding (yeah, I saw Linus' reply in the other thread, full ack on that).
-chris
| |