decreasing #define HZ in the linux kernel for CPU/memory bound apps ?

[Mark Hahn]

> Would it be interesting to decrease the #define HZ in the linux kernel
> for CPU/Memory bound computationnal farms  ?

I'm guessing you're unaware that compute-bound processes
actually get multiple 10ms slices (200ms or so, as I recall,
but I'm remembering a discussion from 2.3.x days.  Ingo's new
scheduler probably preserves this limit.)

> I mean we very often have only one running process eating 99% of 
> the CPU, but we (in fact I) don't know if we loose time doing context
> switches ....

think of the numbers a bit: it's basically impossible to buy
a <1 GHz processor today, so you're getting at O(100M) instrs/HZ.
if you're cache-friendly, you'll probably have >1 instr/cycle,
so scale the number appropriately.  perhaps you're worried about
cache pollution?  the kernel's footprint is fairly small, probably
<4K or so for timer-irq-scheduler-nopreempt.  since a null syscall
is ~1 us or ~1000 instrs, and the work is about the same, I really
don't think there's anything to worry about.

there are people who run HZ=1024 or higher on ia32; I don't personally
think they know what the heck they're doing, but they like it, and 
don't report any serious problems.