* Nick Piggin <npiggin@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
