[To Larry]:
The voodoo point is a good one. Richard does have results that show his
changes to be effective for his program, but he hasn't shown us _why_
they are effective. Sure, fewer cache lines touched etc. but I think we
all agree that doesn't explain his results.
If Richard's changes ever make their way in, without a proper
understanding of the causes those changes will get lost in future
reengineering anyway. There's no point putting them in now, unless it
makes the code simpler.
[To Richard]:
Richard, I suggest you go hunting for the real cause of your wildly
varying numbers. You've found some clues (length of run queue, layout
of task_struct).
You're talking about cache effects. Now those are usually rather subtle
and fragile effects. It's quite possible your fix works because it
changes the length of scheduler function, thereby changing the placement
of various kernel code and data, or some equally fragile reason.
[ Still beats me why L1 data caches don't XOR the low address bits with
a hash of the high address bits to get the line address, it would fix
many of the annoying line conflict problems. ]
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/