Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config-linux: mark memory.kernel[TCP] as NOT RECOMMENDED #1093

Merged
merged 1 commit into from Mar 8, 2021

Conversation

kolyshkin
Copy link
Contributor

Per-cgroup kernel memory accounting (and explicit limiting) is
problematic in the Linux kernel for too many reasons to quote here.
Besides, cgroup v2 does not even have a kernel memory limit knob,
and the one in cgroup v1 is made obsoleted in kernel v5.4 [1].

Mark memory.kernel and memory.kernelTCP as NOT RECOMMENDED, in additon
to OPTIONAL. This is a way to say "we do not anyone (runtimes or users)
to set those limits, unless they have good understanding and strong
reasons to do so".

[1]torvalds/linux@0158115f702b0ba208ab0

Per-cgroup kernel memory accounting (and explicit limiting) is
problematic in the Linux kernel for too many reasons to quote here.
Besides, cgroup v2 does not even have a kernel memory limit knob,
and the one in cgroup v1 is made obsoleted in kernel v5.4 [1].

Mark memory.kernel and memory.kernelTCP as NOT RECOMMENDED, in additon
to OPTIONAL. This is a way to say "we do not anyone (runtimes or users)
to set those limits, unless they have good understanding and strong
reasons to do so".

[1] torvalds/linux@0158115f702b0ba208ab0b

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Comment on lines +267 to +268
* **`kernel`** *(int64, OPTIONAL, NOT RECOMMENDED)* - sets hard limit for kernel memory
* **`kernelTCP`** *(int64, OPTIONAL, NOT RECOMMENDED)* - sets hard limit for kernel TCP buffer memory
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if it would be better to mark them as "deprecated" (as they're deprecated in the Kernel); kept for backward compatibility by runtimes are allowed to ignore them

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. We're using the terms (OPTIONAL, NOT RECOMMENDED) as per RFC2119, and there's no such term as "DEPRECATED" in its lexicon.
  2. This spec (if I understand it right) is for both runtimes and their users. Saying "OPTIONAL" means users can chose to not set these limits, and runtimes can ignore the set limits. Saying NOT RECOMMENDED means users and runtimes should not set those limits, unless there's a good understanding and some compelling reasons to do so.

@mrunalp
Copy link
Contributor

mrunalp commented Mar 8, 2021

LGTM

Approved with PullApprove

Copy link
Member

@tianon tianon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants