Hello.
Lee Revell wrote:
should set CONFIG_HZ to the value I
need at compile-time, and just remove
all the timer reprogramming from the
driver in a hope the dynamic-tick patch
will slow it down itself when necessary?
The current implementations don't allow HZ to go higher than CONFIG_HZ
but that's the next logical step.
What I was thinking about, is that I can
just set CONFIG_HZ to the value I need.
It would be a very high value, but with
the dynamic-tick patch it shouldn't hurt. I
don't see how can I use the dynamic-tick
patch otherwise, I actually though this is
how you implied I should use it.
The question with that approach is just how
to set CONFIG_HZ to an arbitrary values
rather than to the 3 pre-defined constants
(shouldn't be difficult), and whether or not
the dynamic-tick patch will be able to slow
the timer down _that_ much:)
That would actually probably be an ideal
solution for my problem - suddenly I don't
need to change the timer speed at all. The
only limitation would be that when the
speaker driver is enabled in the config,
the ability to manually select the CONFIG_HZ
will be lost, but maybe it is not that bad
at all...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |