>>> On 07.02.18 at 18:08, <andrew.coop...@citrix.com> wrote: > On 07/02/18 15:06, Jan Beulich wrote: >> Also you completely ignore my argument against the seemingly >> random division by 10, including the resulting question of what you >> mean to do once 10Hz also turns out too high a frequency. > > We've got to pick a frequency. The current 100Hz is just as arbitrary > as the proposed new 10Hz.
Not exactly - the 100Hz is simply the frequency we run the main tick at, so while random it is not as random as any further derived value which has no proper reason behind it. There's one more point wrt your argument of overhead: If servicing an NMI takes that long on those boxes, you're basically saying you are happy to waste at least 1% of a core's bandwidth on a debugging feature. Is that reasonable for a production setup? And considering that I'd expect the patch to have chosen e.g. HZ / 5, HZ / 4, or even HZ / 2 if that worked reliably, I could even conclude you're happy to spend somewhere between 5 and 10% of one core's bandwidth. (FAOD all this is based on the 1Hz frequency we - iirc - run the NMI at later on.) To me this is another clear argument to turn off the watchdog on those systems, rather than trying to "fix" its probing. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
