Messages in this thread | | | Date | Wed, 14 Feb 2007 12:04:25 -0800 | From | Zachary Amsden <> | Subject | Re: [PATCH 9/11] Panic delay fix |
| |
Alan wrote: >> We'd have to audit and figure out what udelays are for hardware and >> which are not, but the evidence is that the vast majority of them are >> for hardware and not needed for virtualization. >> > > Which is irrelevant since the hardware drivers won't be used in a > virtualised environment with any kind of performance optimisation. >
Which is why an audit is irrelevant for the most part. Note on the performance below.
>> Changing udelay to "hardware_udelay" or something all over the kernel >> would have delayed the paravirt_ops merge by an infinite amount 8) >> > > paravirt_ops has no business fiddling with udelay. Not only does it > create more code bloat and stalls in relatively fast paths but its > optimising the wrong thing anyway. >
??? I fail to see the code bloat and also the fast paths. Which fast paths use udelay?
> My performance sucks -> optimise out udelay is the wrong approach. My > performance sucks, switch to the virtual block driver is the right > approach, and a virtual block driver won't be using udelay anyway >
This is not to stop performance from sucking. It doesn't. This is not an "approach". Sure, a virtual block driver won't be using udelay. Everyone else who writes hypervisors writes virtual block drivers because they don't have optimized I/O emulation for real hardware. Their performance sucks without it because they have to go switch to some other context and run a device emulator. Our doesn't. We have optimized almost every I/O device we emulate. But sitting around spinning in udelay is wasting everybody's time. There is an overhead cost to trapping out on I/O instructions. Removing the udelays that typically happen around I/O instructions causes the emulation to break even.
And that is a good thing. It's certainly not required, nor is it a significant win while the kernel is running. It does cut the boot time by a lot, and you will notice an obvious difference with a much faster kernel boot simply because a lot of the hardware setup has very conservative udelays which take a lot of time during device initialization. Since boot time * number of reboots has a direct impact on the number of 9's you can claim for uptime, this is actually a large win for reliability.
Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |