Hola amigos!
I know it's been a long time since I rapped at ya'. Here we are, in '06, more than half-way through the "oughts." How will our decade be remembered? I shudder to think.
It looks like Sun is going to build hardware virtualization support into the newer niagara parts. I must confess that this one is a bit of a head-scratcher for yours truly. The only OS'es of significance that run on sparc are Solaris and Linux. Persons running Linux on sparc hardware for anything other than software development or entertainment purposes are, not to put too fine a point on it, probably out of their cotton-picking minds. So, why does Sun think this will enable them to sell more servers, especially given that their (oh, so horrendously named) BrandZ magic sauce lets most Linux applications run on top of Solaris? Beats me. Perhaps they felt they had to be able to counter Intel's substantial VT hype?
Speaking of which ... Simon Crosby was at Stanford flogging Xen yesterday. While I was unfortunately not able to make it, I perused the slides a tad. With foil titles like "XenSource Delivers Virtualization Value", there isn't much academic veneer on this very business-oriented talk, so, as a non-expert, I can do little to address the projections, pie charts, etc. However, I notice from slide 27 that they're relying on page-table switching to protect virtual kernels from virtual applications on 64-bit architectures. The slide is oddly silent on what a flaming performance disaster this approach constitutes. As if turning every virtual system call into two hardware system calls weren't enough, we're now piling a TLB flush on top of that cost, too. I'll be interested to see how their 64-bit performance fares compared to our offerings. But hey! Who cares about performance when you're "the Open Industry Standard," "Unlocking Platform Innovation"! I'm also tickled at the extended treatment of Xen's newfound live migration capabilities, as if we hadn't shipped the very feature they're aping in 2002.
I know, I know, it's a low blow. VMware has some pretty goofy marketing material out there, too. We're not presenting it in front of the Stanford CS department, though. For the most part. I think.
It looks like Sun is going to build hardware virtualization support into the newer niagara parts. I must confess that this one is a bit of a head-scratcher for yours truly. The only OS'es of significance that run on sparc are Solaris and Linux. Persons running Linux on sparc hardware for anything other than software development or entertainment purposes are, not to put too fine a point on it, probably out of their cotton-picking minds. So, why does Sun think this will enable them to sell more servers, especially given that their (oh, so horrendously named) BrandZ magic sauce lets most Linux applications run on top of Solaris? Beats me. Perhaps they felt they had to be able to counter Intel's substantial VT hype?
Speaking of which ... Simon Crosby was at Stanford flogging Xen yesterday. While I was unfortunately not able to make it, I perused the slides a tad. With foil titles like "XenSource Delivers Virtualization Value", there isn't much academic veneer on this very business-oriented talk, so, as a non-expert, I can do little to address the projections, pie charts, etc. However, I notice from slide 27 that they're relying on page-table switching to protect virtual kernels from virtual applications on 64-bit architectures. The slide is oddly silent on what a flaming performance disaster this approach constitutes. As if turning every virtual system call into two hardware system calls weren't enough, we're now piling a TLB flush on top of that cost, too. I'll be interested to see how their 64-bit performance fares compared to our offerings. But hey! Who cares about performance when you're "the Open Industry Standard," "Unlocking Platform Innovation"! I'm also tickled at the extended treatment of Xen's newfound live migration capabilities, as if we hadn't shipped the very feature they're aping in 2002.
I know, I know, it's a low blow. VMware has some pretty goofy marketing material out there, too. We're not presenting it in front of the Stanford CS department, though. For the most part. I think.
posted by Keith Adams at 10:48 AM
2 Comments:
I make no excuses for VMware's retarded EULA. I think it ultimately hurts us, since as you imply here, it makes it look like we've got something to hide.
TLB flushes are TLB flushes, though. When Linux's 4G/4G patch introduced a TLB flush on every system call, the roof caved in. Have fun resurrecting this approach.
Sorry for the flames. Didn't know we had fan-boys :-)
I'm sure you realize that we had the same problem ya'll did since segmentation isn't available on the x86-64. In fact, I had heard that AMD added it back in newer models specifically at VMware's request :-)
At any rate, the benchmarks haven't been so bad so far. Slides from the recent XenSummit should be available soon with the actual numbers.
Strictly speaking, the whole TLB doesn't have to be flushed. Unlike the 4GB/4GB patch, we simply do not map in the kernel space when in usermode. We only have to invalidate the PGD for kernelspace.
BTW, XenSource != Xen. Many of us are just as annoyed at the XenSource marketing stuff as you :-)
Post a Comment
<< Home