On Mon, 03 Jul 2000, Alan Cox wrote:
> > no HZ=1000 is not needed , since your task get woken up by
> > blocking write() to /dev/dsp.
>
> This doesnt work for mmap, and you need the finer granularity than some
> cards can provide. Using HZ=1000 materially improves the feel of Linux x86
> on modern CPUs and also appears to improve throughput not reduce it
Yes, I know that's why I often use RTC in combination with mmap.
As for HZ = 1000 : besides the fact that there was a discussion on k-l about
the slowdown of a few % (kernel compilation tests) and the userspace /
kernelspace HZ issues which may break some apps ,
it would be nice to achieve good granularity when calling usleep() (or
nanosleep()).
As far as I know HZ = 1000 improves the minimum usleep() time to 2msecs
(from 20msecs when HZ = 100) , but that is still not enough for multimedia
stuff.
I am more for an UTIME like approach where you achieve timing granulartiy
of sub-msec precision.
I agree that the throughput can in some cases be improved by higher HZ,
but these 100msec stalls ruin everything. (I see the min usleep() time
of 2msec (with 1msec granulariy) of HZ=1000 as almost useless,
because as soon I touch the machine, the 1msec granularity will be largely
overshadowed by scheduling noise which about 30-50times bigger.
Benno.
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:11 EST