It isn't just me then, huh? I tried to bisect my way to a precise patch but it's really hard when you have ~15 steps, it's hard to tell if it "works" or not in anything less than an hour, and if you're wrong once you're guaranteed not to find the correct one. And the results I got almost make me think it's actually more than one patch combining together such that it has actually gotten gradually worse over time, which makes it even harder to finger.
I think it's time to have some unit tests written and get bolder with refactoring. I remember smarter-than-me developers claiming it's impossible to have tests in the kernel, but I never quite got a satisfactory answer. BTW, is there a USB connected power meter that could be used to reliably measure power consumption? It's easy to setup abox that continuously deploys different kernel configurations and measures power consumption. With something like that we could have a good map of power consumption x kernel x hardware in a couple days.
But that would be a manual step. The idea behind this would be to let the box build and test a succession of kernels, patch by patch, automatically, to find a regression.
I wouldn't want to manually test a hundred kernels, but I can easily spare a box for a week.
All we would need would be some way to gauge the instantaneous consumption at reading time. I would assume the tested kernel is capable of, at least, boot, check its power consumption under some workload (maybe compiling the kernel with the next patch set to be tested) and dumping that information to a file or a remote machine.
Maybe he should reconsider his stance on microkernels. It would be interesting if the original GNU OS idea (Hurd) was revived. Splitting up the thing will into separate processes would certainly help against bloat.
Apple did that for a while with MkLinux before settling on NEXTSTEP. It ran fine on PPC Macs, and was based on a Mach microkernel. I converted lots of unused PowerMacintoshes nobody wanted (with MacOS 8 I can't blame them) at my then company to Unix workstations with that. When I later visited, every developer had one on their desk along their x86 PC.
I installed/upgraded ArchLinux (which is at 2.6.38 now) on a bunch of laptops lately and noticed a raise in power usage (in the range of 10%), with mostly some high kworker activity (100+ wakeup/s when idle, that's 80% of overall wakeups) in powertop. But the worst contender has been s2ram power usage: the laptops go to sleep yet leaving them sleeping overnight pumps 40% out of the battery (should be 2~4%, tops). Unfortunately I can't downgrade easily as .38 introduced proper support for core components of those laptops.
.38 introduced lot's of new stuff [1], so regressions can occur I guess.
But I know that it'll get fixed. By the time this news got to HN there's probably someone working on it.
Transparent huge pages (also new in 2.6.38) have caused about 5% degradation in memory bandwidth (measured by STREAM benchmarks and other kernels, independent of the use of software prefetch) on my machines. This is somewhat strange because huge pages should help this benchmark.
