Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-*

[Flavio Veloso <flaviovs@magnux.com>]

Thank you for your comments.

To be very honest, I never did much research about this subject -- and 
for the reasons I explained before I always use 100Hz when recompiling 
for server usage. I can't comment about big SMPs but I always thought 
that the interrupts are routed independently, but I might have 
misunderstood that. Server usage is more sensitive to load than 
responsiveness IMHO, so to me the less context switches the better (and 
that's what we get with 100Hz, which used to be the default before 250Hz 
-- and 1KHz -- was introduced as a compromise between server and low 
latency for desktop-oriented tasks). I do not think that network latency 
plays a big hole here as net jitter alone can be much larger than the 
numbers we're talking here (specially in cloud/VPS environment). Lastly, 
I think that "because Amazon does" is not a good reason for not 
implementing it -- it might just be that they don't care about their 
users as we do.

Anyway, non-authoritative answers here too, so hopefully someone more 
knowledgeable than I am might jump in and enlighten us! :-)

On 2019-09-27 9:15 p.m., Nicholas D Steeves wrote:
> Noah Meyerhans <noahm@debian.org> writes:
>
> > On Fri, Sep 27, 2019 at 01:15:29PM -0700, Flavio Veloso wrote:
> > > Since linux-image-cloud-* packages are created for cloud environments --
> > > read: servers which do not need desktop-level responsiveness --, wouldn't it
> > > be beneficial to build the kernels with CONFIG_HZ set to 100?
> I wonder if the upstream docstring could be improved, because to my mind
> 100hz only makes sense for throughput-limited workloads, or for big SMP
> systems. eg: when you have one 100hz timer running on each of 32 cores
> the effect on latency is more like a ~3200hz timer than a 100hz one.
>
> Also, network latency is a big deal now, so I'm not sure if this
> docstring is accurate anymore.
>
> > For what it's worth, the Amazon Linux 2 4.14.x kernel also ships with
> > CONFIG_HZ=250. We obviously don't need to use the same settings, but
> > that kernel specifically targets cloud deployments, and its maintainers
> > do not see a need to set CONFIG_HZ=100.
> >
> > I don't know what considerations were taken into account when choosing
> > the value for that variable at AWS.
> Maybe something like socket activation, subprocess or thread creation
> latency?  Or maybe because it's useful to have a 250hz timer when your
> vhost only has one vcpu?
>
> 'just some non-authoritative thoughts.  I'm sure Ben can say for sure
> :-)
>
> Take care!
> Nicholas

--
FV