Hi Krister,

(I am not in the Kernel Team, but in SEG)

The Kernel Team are quite specific to what patches they accept, and they pretty
much just stick to correctly formatted patches.

You can find the documentation for patch formatting here:

https://canonical-kernel-docs.readthedocs-
hosted.com/latest/reference/stable-patch-format/

To get you on the right track:

- [Impact] is good, I think this is a reasonable request as any existing
userspace applications that use cgroups v1 should still run on HWE kernels, and
plucky's kernel breaks this.

- [Fix] needs some work. Why just CONFIG_MEMCG_V1? just because your workload
needs it? What about other users? Looking at man (7) cgroups, and reading about
cgroups v1, and then doing a grep against my current running kernel,
6.17.0-4-generic on questing:

CONFIG_CGROUP_SCHED=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CPUSETS
233:CONFIG_CPUSETS=y
234:# CONFIG_CPUSETS_V1 is not set
CONFIG_MEMCG
215:CONFIG_MEMCG=y
216:# CONFIG_MEMCG_V1 is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_BLK_CGROUP*=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_NET_PRIO=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_RDMA=y

Theres both CONFIG_CPUSETS_V1 and CONFIG_MEMCG_V1. Should CONFIG_CPUSETS_V1 be
enabled too? Why? Why not?

- [Testcase], ideally you would explain how a user can see that v1 cgroups
are present again. It should show a clear case of failure, and a clear case of
success. What commands can a user run to see each cgroup mount point? Run a
process in one of these cgroups to check it still works etc?

- [Potential Regression] / should really be named [Where problems can occur].
There is always risk of a regression happening. What could go wrong? If a
regression were to occur, what would break, what would it look like, how can we
mitigate it?

As for the patch submission itself:

- The patch needs a cover letter and the patch needs to be sent separately as
a reply to the cover letter. Use

$ git format-patch --cover-letter --subject-
prefix="[SRU][N:hwe-6.14][PATCH"

so it generates you a cover letter and it is clear it is for noble's 6.14
HWE kernel.

- The subject of the patch needs to be "UBUNTU: [Config] blah" e.g.
"UBUNTU: [Config] Enable cgroup v1 support". This makes it easily greppable in
the git tree when we go looking for config changes later on.

- You patched against "debian.master/config/annotations". This is for noble's
6.8 kernel only. To get the 6.14 hwe, check out the git tag. e.g.

$ git checkout Ubuntu-hwe-6.14-6.14.0-29.29_24.04.1 
or 
$ git checkout origin/hwe-6.14-next

then you see a debian.hwe-6.14/ directory. Make you changes to the config in
this directory instead.

Again, consider also adding back support for CONFIG_CPUSETS_V1.

Have a read of the patch docs, and let me know if you need any help! I can also
review any patches before you submit them to the kernel team mailing list.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2122368

Title:
  Re-enable memcg v1 on Noble (6.14)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122368/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to