Re: CVS commit: src/sys
In article <20111025172130.GA1184@marx.bitnet>, Jukka Ruohonen wrote: >On Tue, Oct 25, 2011 at 04:04:35PM +, Christos Zoulas wrote: >> In this case a simple change from: >> s += ntb.tv_nsec; >> to: >> s += ntb.tv_nsec / 1000; >> would have been sufficient since the division is outside the critical >> sampling section. > >Heh, obviously. I'll put it back then. >> Could be, but in the long term I prefer us to have only one timing >> scale in the kernel to avoid conversions, confusion, and gain back >> some efficiency in the basic timekeeping code which now needs to >> keep track of both micros and nanos. > >Another nice thing would be a KPI for sampling things like this (e.g. more >robust measures like medium, harmonic mean, etc.). Or even something that >could enable this kind of profiling on-demand. (I know, DTrace is there.) I totally agree. Perhaps a SoC project? christos
Re: CVS commit: src/sys
On Tue, Oct 25, 2011 at 04:04:35PM +, Christos Zoulas wrote: > In this case a simple change from: >s += ntb.tv_nsec; > to: >s += ntb.tv_nsec / 1000; > would have been sufficient since the division is outside the critical > sampling section. Heh, obviously. > Could be, but in the long term I prefer us to have only one timing > scale in the kernel to avoid conversions, confusion, and gain back > some efficiency in the basic timekeeping code which now needs to > keep track of both micros and nanos. Another nice thing would be a KPI for sampling things like this (e.g. more robust measures like medium, harmonic mean, etc.). Or even something that could enable this kind of profiling on-demand. (I know, DTrace is there.) - Jukka.
Re: CVS commit: src/sys
In article <20111025150023.GA13544@marx.bitnet>, Jukka Ruohonen wrote: >On Tue, Oct 25, 2011 at 02:36:50PM +, Christos Zoulas wrote: >> We really want to be switching most things in the kernel to timespec from >> timeval not the other way around? > >A case came up where the transition latencies are very high, and I'd like >to still use uint64_t. The precision is hardly important here (something >like 10 * usec is fine). In this case a simple change from: s += ntb.tv_nsec; to: s += ntb.tv_nsec / 1000; would have been sufficient since the division is outside the critical sampling section. You could remove the unneeded 0 assignments above the critical section too to gain back the lost code size :-). >> This is backwards as things tend to become faster instead of slower. > >In this case (the sampling itself) things might even become slower (i.e. >more CPUs), mainly due NetBSD (xcall), but still. Could be, but in the long term I prefer us to have only one timing scale in the kernel to avoid conversions, confusion, and gain back some efficiency in the basic timekeeping code which now needs to keep track of both micros and nanos. christos
Re: CVS commit: src/sys
On Tue, Oct 25, 2011 at 02:36:50PM +, Christos Zoulas wrote: > We really want to be switching most things in the kernel to timespec from > timeval not the other way around? A case came up where the transition latencies are very high, and I'd like to still use uint64_t. The precision is hardly important here (something like 10 * usec is fine). > This is backwards as things tend to become faster instead of slower. In this case (the sampling itself) things might even become slower (i.e. more CPUs), mainly due NetBSD (xcall), but still. - Jukka.
Re: CVS commit: src/sys
In article <20111025113549.edb0a17...@cvs.netbsd.org>, Jukka Ruohonen wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: jruoho >Date: Tue Oct 25 11:35:49 UTC 2011 > >Modified Files: > src/sys/kern: subr_cpufreq.c > src/sys/sys: cpufreq.h > >Log Message: >Use microsecond rather than nanosecond resolution when sampling latencies. Why? This is backwards as things tend to become faster instead of slower. We really want to be switching most things in the kernel to timespec from timeval not the other way around? christos
