Re: [PATCH] mm/vmstat: spread vmstat_update requeue across the stat interval

[Breno Leitao <leitao@debian.org>]

> > 
> > Cool!
> > 
> > I noticed __round_jiffies_relative() exists and the description looks like
> > it's meant for exactly this use case?
> 
> On closer look, using round_jiffies_relative() as before your patch
> means it's calling __round_jiffies_relative(j, raw_smp_processor_id())
> so that's already doing this spread internally. You're also relying
> smp_processor_id() so it's not about using a different cpu id.
> 
> But your patch has better results, why? I still think it's not doing
> what it intends - I think it makes every cpu have different interval
> length (up to twice the original length), not skew. Is it that, or that
> the 3 jiffies skew per cpu used in round_jiffies_common() is
> insufficient? Or it a bug in its skew implementation?
> 
> Ideally once that's clear, the findings could be used to improve
> round_jiffies_common() and hopefully there's nothing here that's vmstat
> specific.

Excellent observation. I believe there are two key differences:

1) The interval duration now varies per CPU. Specifically, vmstat_update()
   is scheduled at sysctl_stat_interval*2 for the highest CPU with my
   proposed change, rather than a uniform sysctl_stat_interval across
   all CPUs. (as you raised in the first email)

2) round_jiffies_relative() applies a 3-jiffies shift per CPU, whereas
   vmstat_spread_delay distributes all CPUs across the full second
   interval. (My tests were on HZ=1000)

I'll investigate this further to provide more concrete data.

Thanks for the review,
--breno