On Fri, Dec 15, 2006 at 12:20:46PM +0000, Simon Riggs wrote: > > I > > wrote a patch that tried statistical sampling, but the figures were too > > far off for people's liking. > > Well, I like your ideas, so if you have any more... > > Maybe sampling every 10 rows will bring things down to an acceptable > level (after the first N). You tried less than 10 didn't you?
Yeah, it reduced the number of calls as the count got larger. It broke somewhere, though I don't quite remember why. > Maybe we can count how many real I/Os were required to perform each > particular row, so we can adjust the time per row based upon I/Os. ISTM > that sampling at too low a rate means we can't spot the effects of cache > and I/O which can often be low frequency but high impact. One idea is to sample at fixed interval. Where the I/O cost is high, there'll be a lot of sampling points. The issue being that the final result are not totally accurate anymore. > > I think the best option is setitimer(), but it's not POSIX so > > platform support is going to be patchy. > > Don't understand that. I thought that was to do with alarms and signals. On my system the manpage say setitimer() conforms to: SVr4, 4.4BSD. I'm unsure how many of the supported platforms fall under that catagorisation. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
