Why not just try and modify the time slice scale? wouldn't this then
help with what you are trying to gain, while leaving other values alone
that rely on 100HZ?
Doesn't an unmodified TICK_SCALE negate most of the lowered time slice
effect you'd gain from raising HZ anyway?
Seems like Ingo did a bunch of work on trying to get the "sweet spot"
time slice quanta value already, and I don't think he did it with the HZ
value, but I could be wrong.
And if it is Xwindows performance you are trying for, it's not the
kernel (flying by the seat of my pants here). I can have crappy X
performance and yet my audio never skips a beat, running at exactly the
same priority as X(though my X perf problems seem to stem from multiple
clients rendering on screen at the same time.;-)(No disrespect to the X
developers, since it does a lot of thing very nicely :-)
Dan
On Tue, 2002-04-16 at 20:57, Robert Love wrote:
> On Tue, 2002-04-16 at 20:49, David Mosberger wrote:
>
> > But since it's popular, I did measure it quickly on a relatively
> > slow (old) Itanium box: with 100Hz, the kernel compile was about
> > 0.6% faster than with 1024Hz (2.4.18 UP kernel).
>
> One question I have always had is why 1024 and not 1000 ?
> Because that is what Alpha does? It seems to me there is no reason for
> a power-of-two timer value, and using 1024 vs 1000 just makes the math
> and rounding more difficult.
>
> Robert Love
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:17 EST