I wasn't sure what the current state was with the kernel.

I remember reading awhile back where someone did compile a kernel largely without optimization, and they showed around a 5% shift in overall system performance as a result. That makes sense: Ideally, the kernel's algorithms (and their O(x) characteristics) have the largest impact on performance, especially the algorithms for scheduling tasks and I/O. The *implementation* of those algorithms (aside from details that affect big-Oh) should have minimal impact in most cases.

I'd expect microbenchmarks that focus on specific kernel paths (such as loopback-crypto-filesystems and raw pipe bandwidth) to suffer if the kernel was built without optimization. I would not expect overall system performance to shift dramatically otherwise. Under most loads I deal with (like kernel compilation and random web browsing), the kernel uses less than 10% of the system's cycles, and most often uses far less than 5%. Even if the kernel slowed down 300% or more, that'd still shift most userland performance figures minimally.

For example, suppose a given workload benchmarked on an optimized kernel resulted in 10% of the cycles spent in the kernel not waiting for I/O. Now suppose the kernel's execution time slowed down by 3x because we disabled optimization. Then the overall benchmark would be at most 20% slower--that is, take 1.2x as long.

I hear you on -Os vs. -O2. I work with embedded processors in my line of work. Program cache footprint is a huge concern for our customers, and the impact of program size, layout and so on has a gigantic impact on the ultimate performance of their application. Indeed, probably the strangest outcome I've witnessed is the impact of instruction-level parallelism in a deeply pipelined processor: If your code isn't highly parallel, then you won't notice instruction cache misses quite so much. But that's a topic for different forums. :-)