Re: [PATCH 9/11] Panic delay fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux