Peter Williams wrote: > > I've done some informal testing with smaller values of CAP_STATS_OFFSET > and there is only a minor improvement. > > However, something that does improve behaviour for short lived tasks is > to increase the value of HZ. This is because the basic unit of CPU > allocation by the scheduler is 1/HZ and this is also the minimum time > (and granularity) with which sinbinning and other capping measures can > be implemented. This is the fundamental limiting factor for the > accuracy of capping i.e. if everything worked perfectly the best > granularity that can be expected from capping of short lived tasks is > 1000 / (HZ * duration) where duration is in seconds.
I already defines CONFIG_HZ=1000. Do you suggest increasing more? > For longer living tasks, once the initial phase has passed the half life > of the Kalman filters takes over from "HZ * duration" in the above > expression. Reducing CAP_STATS_OFFSET will shorten the half life of the > filters and this in turn will make capping coarser. On the other hand, > if the half lives are too big then capping will be too slow in reacting > to changes in a task's CPU usage patterns. So there's a sweet spot in > there somewhere. There's also an upper limit imposed by the likelihood > of arithmetic overflow during the calculations and this has to consider > the fact that the average cycle length (one of the metrics) can be quite > long. The current values was based on these considerations. > > Peter Thanks, MAEDA Naoaki _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
