Re: any chance of 2.6.0-test*?

[Matti Aarnio]

On Sun, Jan 12, 2003 at 09:19:28PM -0500, Rob Wilkens wrote:
> On Sun, 2003-01-12 at 20:51, Nuno Monteiro wrote:
> > You dont realistically expect to learn how to program reading 
> > Documentation/CodingStyle, do you? CodingStyle merely serves as general 
> 
> No, but I would expect rules of kernel coding to be in there.  For
> example, we were talking about using return mid-function.  I always
> considerred that perfectly OK.  Others were saying that's a no-no.  If
> it's a no-no, it should be documented.  That is, if it's a no-no.  That
> may be a situational thing though.

That document is short for several reasons.

- It has been written for particular needs, and updated rarely

- Most long-time kernel coders really don't need detailed guidelines,
  although newcomers (like yourself) apparently want something..

Things you need to understand include at least:

- Linux kernel is one of the most complicated codes that gcc compiler
  is ever put to work on, and over the years we have unearthed tons of
  optimizer bugs.    Many of somewhat odd looking coding details do
  originate from circumventions of those compiler bugs.

- Advanced optimizer hinting features, like   unlikely()  attribute
  are very new in (this) compiler, and while they in theory move the 
  "unlikely" codes out of the fast-path, such things have been buggy
  in the past, and we are worried of bug effects...

- Why code in a manner, where the optimizer needs to work very hard to
  produce fast code, when simplified structures, like those with 'goto'
  in them, can result the same with much less effort ?

- Knowing effects of those optimizations requires profiling, and studying
  produced assembly code on different target systems.

- Linux is multi-CPU-architecture kernel, looking at it via "intel-only,
  lattest Pentium-XIV" viewpoint is not going to cover all cases.  Making
  changes that bloat code will make system that much harder to fit into
  smaller embedded machines.

- Sometimes you need to code differently to achieve higher performance
  at different processors.  See   drivers/md/xor.c   and header files
  it includes.  Especially all  include/asm-*/xor.h  files, including
  include/asm-generic/xor.h ...   (That shows to you how different
  approaches work at different systems.  What works fast in register-
  rich processors does not necessarily be fast in register-poor things,
  like i386 series.)

- Adding function classifiers like "static inline" do change rules 
  somewhat. (Especially things like "mid-function return".)

- Larger code, either with manually replicated exit cleanup (which
  are pain to maintain, when some large-scale change is needed), or
  via excessive use of "static inline", will pressure caches, and
  makes it more likely to drop soon to be again needed code (or data)
  from cache.    Cases where cache-miss costs your tens, or hundreds
  of processor clock cycles that is really important question.

- Explaining things like GCC asm() statement syntaxes isn't a thing
  for Linux kernel documentation.  (Those vary from target processor
  to another!)

I repeat:

To understand effects of various coding details, you need to study produced
assembly code, and keep in mind that in modern processors a branch out of
straight-line execution path (after optimizations) is expensive (in time),
and cache-misses are even more expensive.

Then you need to benchmark those codes with different loads (where 
applicable) to find out what caches affect them -- and when you must
bypass caches (they are limited resource, after all) in order to give
overall improved system performance, when your code does not cause
actively used code or data to be evicted from caches unnecessarily.

> -Rob

/Matti Aarnio