Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #65239 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-* Flavio Veloso <flaviovs@magnux.com> - 2019-09-27 22:50 +0200
    Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-* Noah Meyerhans <noahm@debian.org> - 2019-09-28 00:40 +0200
      Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-* Nicholas D Steeves <nsteeves@gmail.com> - 2019-09-28 06:20 +0200
        Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-* Flavio Veloso <flaviovs@magnux.com> - 2019-10-01 01:40 +0200

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

Package: linux-image-cloud-amd64
Version: 4.19+105+deb10u1
Severity: wishlist

Hello,

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 guess I do not need to explain the compromise behind timer 
overhead/context switching/RT responsiveness/etc. when choosing 100Hz, 
250Hz (the default), or 1KHz, but here's an except from Kconfig's help: 
"100 Hz is a typical choice for servers, SMP and NUMA systems with lots 
of processors that may show reduced performance if too many timer 
interrupts are occurring."

Beside the reduced timer overhead and potential higher throughput, this 
also would reduce the size of the kernel (https://lwn.net/Articles/56378/).

Regards,
-- 
FV

[toc] | [next] | [standalone]

#65246

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?

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.

noah

[toc] | [prev] | [next] | [standalone]

#65248

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#65262

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web