Linux: CONFIG_CFS_BANDWIDTH not set

Created on 6 Dec 2017  路  19Comments  路  Source: raspberrypi/linux

Hi,

I'm heavily using Docker on raspian. My system:

  • raspian stretch
  • Linux docker1 4.14.4-v7+ #1060 SMP Tue Dec 5 16:01:44 GMT 2017 armv7l GNU/Linux
    (i'm already on BRANCH next for rpi-update)

The current kernel lacks the support for config_cfs_bandwith. It's usefull with docker when you want to limit the cpu usage on your container (and since the raspberry pi is a small machine, i think it's a good idea).

% zgrep CONFIG_CFS_BANDWIDTH /proc/config.gz
# CONFIG_CFS_BANDWIDTH is not set

% /usr/share/docker-ce/contrib/check-config.sh

  • CONFIG_CFS_BANDWIDTH: missing

I don't know if there is a downside to enable it (impact on performance or size or both maybe).
An another solution would be to activate it on demand (i already put "cgroup_enable=memory swapaccount=1" on /boot/cmdline.txt to enable the cfs memory ).

Regards,

Close within 30 days Waiting for external input

Most helpful comment

I'd like this feature too to be able to tune CPU share of docker containers I'm running on my RPi 4.
If performance impact is the issue, why not disabling it by default and allowing interested parties to enable via cmdline.txt tunable or at least custom kernel image.

Either way, a lot of people are running Docker containers on their Pi's, why not accommodate them? :)

All 19 comments

Since this is a small use case, we would want to see kernel impact information - speed, size - before we can decide on this.

Is it not possible to enable it only on demand ? (like memory cgroup)

That is the question. When somebody comes to us with a niche request like this it helps their case a lot if they can show the impact on kernel memory footprint and performance when the feature is available but disabled (if that is possible).

No, it's not possible to make it on-demand only, it's either compiled in, or not. It won't be used if you don't create any CPU cgroups, but the code is still there and does still have an impact on performance (although based on what I've seen on other systems, the runtime performance impact is close enough to zero to not matter except for hard-realtime applications).

If those other systems are quad core i7 3Ghz devices then I'm sure they can take the hit, but we really need to know the hit on the Pi1/0 since our kernel is used for those slow devices.

It's not measurable on a decent i7 without using perf to count cycles, but I've also tested on some dinky little Braswell chips (4 cores, no hyper-threading, 1.6GHz normal, 2.4GHz burst), and the hit was barely measurable there too. Unfortunately, I don't currently have a Pi that I can spare to test this on, and I never checked the memory overhead (a few kB generally doesn't matter when you have 4G of RAM, so I never saw any need to check at the time), so you'll need someone else to check that.

Without accurate performance impact figures, this isn't going to progress very far....anyone have any? I'm inclined to close with 30 days if no figures are forthcoming.

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

Not the original requester, but I'd be interested in CONFIG_CFS_BANDWIDTH from an educational standpoint. I wanted to demonstrate how you could limit the impact of hungry programs (like stress 馃槢 ) on your Pi using the cpu.cfs_period_us and cpu.cfs_quota_us cgroups and I was sad to find them missing. 馃槩 Just my two-cents! I'm sure you have good reasons for being conservative with enabling these kernel features.

As stated above, we need some indication of the impact of the change on CPU and memory for the standard user case. If there is generally no impact then we can add stuff, but on a limited resource device like the Pi we are hesitant to add anything that might detrimentally affect all users but only benefit a few.

Feel free to build a kernel with this changed and report back the impact over standard, and we can make a decision.

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.

I'm interested in this feature, too. I do have a Pi 0 W and I'd be happy to run some tests 馃憤

I'm not familiar with how to test performance as requested. Do you typically use certain benchmarks/tools or is there a good guide you'd recommend?

I would also like to see cfs quota / cfs bandwidth support in the Raspbian kernel. While I understand the concern on memory and cpu overhead, now with 4 core, 4GB RAM Raspberry Pis, this needs to be addressed.

I'd like this feature too to be able to tune CPU share of docker containers I'm running on my RPi 4.
If performance impact is the issue, why not disabling it by default and allowing interested parties to enable via cmdline.txt tunable or at least custom kernel image.

Either way, a lot of people are running Docker containers on their Pi's, why not accommodate them? :)

Please I use Docker too I need this ! My nextcloud is KO after this features was remove :'(

Now those CPU cycles are wasted spamming the log when running light weight Kubernetes such as K3S.

Can this be reconsidered or provide an alternative kernel? The recent Raspberry PI 4 is a bit more powerful.

I don't mind building my own kernel, but having one provided would lower the barrier.

Having this flag in reduces friction and noise when educating Kubernetes.

Then one can watch the host log for other problems instead of noise.

CFS_BANDWIDTH has been enabled in the standard Pi defconfigs since 5.4.61/62. Any kernel releases since Sep 1 2020 have it included.

All work now, thank you !

Thanks for the clarification. I will do some further digging to see whether the problem is between keyboard and chair or bug elsewhere.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pvouzis picture pvouzis  路  9Comments

incyi picture incyi  路  9Comments

Nuntis-Spayz picture Nuntis-Spayz  路  5Comments

awlx picture awlx  路  4Comments

fivdi picture fivdi  路  9Comments