John Polstra wrote: > After 25 minutes testing that with NTIMECOUNTER=50000, I haven't > gotten any microuptime messages. So it appears that my problem was > just that the current timecounter wrapped all the way around the ring > while microuptime was interrupted, due to the high HZ value and the > heavy interrupt load. I'm sorry I didn't try this sooner, when you > suggested it. > > After lunch I'll try NTIMECOUNTER=HZ (10000 in my case). That sounds > like a nice default value to me.
5 * HZ @ 10,000 HZ * sizeof(struct timecounter) = 5 * 10000 * 23*4 = 4,600,000 = 4.5M in timecounter structures Even with your NTIMECOUNTER=HZ (assuming it even works), that is 1M of memory burned on timecounter structures to prevent wrap around. If the interrupts are happening fast enough that wrap is this bad a problem, then I suggest another counter that divides the interupt frequency down to a (much smaller) update frequency for the timecounter. Is having this many of these things really worthwhile? I can't see how off the top of my head, but I can imagine a situation where it miht be referenced with a higher than wrap frequency... but the question is, what's the highest access frequency? That should limit the update frequency to twice that, right, which would guarantee adequate update resolution to satisfy that use? If it is, could we maybe just count wraps, instead, and add 7.7? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
