Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 20 Jan 2009 13:38:24 +0100 | From | Ingo Molnar <> | Subject | Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning |
| |
* Nick Piggin <npiggin@suse.de> wrote:
> > > it seems like a nice opt-in thing that can be used where the aliases > > > are verified and the code is particularly performance critical... > > > > Yes. I think we could use it in the kernel, although I'm not sure how > > many cases we would ever find where we really care. > > Yeah, we don't tend to do a lot of intensive data processing, so it is > normally the cache misses that hurt most as you noted earlier. > > Some places it might be appropriate, though. It might be nice if it can > bring code size down too...
I checked, its size effects were miniscule [0.17%] on the x86 defconfig kernel and it seems to be a clear loss in total cost as there would be an ongoing maintenance cost of this weird new variant of C that language lawyers legislated out of thin air and which departs so significantly from time-tested C coding concepts and practices.
We'd have to work around aliasing warnings of the compiler again and again with no upside and in fact i'd argue that the resulting code is _less_ clean.
The lack of data processing complexity in the kernel is not a surprise: the kernel is really just a conduit/abstractor between hw and apps, and rarely generates genuinely new information. (In fact it can be generally considered a broken system call concept if such data processing _has_ to be conducted somewhere in the kernel.)
( Notable exceptions would be the crypto code and the RAID5 [XOR checksum] and RAID6 [polinomial checksums] code - but those tend to be seriously hand-optimized already, with the most critical bits written in assembly. )
Ingo
| ![\](/images/icornerr.gif) |