Using CPU limit with share influence under load (limits.cpu.allowance & priority & cgroup shares)

[dionysius]

Required information

• Distribution: independent
• LXD version: branch master (currently commit sha ed9782036ed847a0306bf6873bf8f96cf1786204)

Issue description: Feature request

Currently it's not possible to use a hard cpu time limit (currently limits.cpu.allowance with _ms/_ms notation, which basically sets cgroup cpu quota and period) with a cpu time sharing indicator under load (currently limits.cpu.allowance with _%, which sets cgroup cpu shares) because it's the same field. The way how it's currently implemented: If you use the hard cpu time limit, the average cpu time you get under heavy load is basically around a 1/th of all available cpu assuming all containers are using cpu. I'd like to influence that a container can have more or less of that share under load than others. The knob limits.cpu.priority only sets the cgroup cpu shares up to 10 shares less, which is very marginal with the default cpu share of 1024 (sounds like it influences around 1% at max). Side note: Is limits.cpu.priority in any case impactful?

I would like to use limits.cpu.allowance with the cpu time limit notation, and some additional field to greatly influence the cgroup cpu shares (also setting it above 1024).

Suggestion

I assume it's wished to not having exactly the raw field value, so:

• changing the limits.cpu.priority to another format (would be an API change - and I don't know if that knob changes somewhere anything else)
• introduce another field name, E.g. weight or share_weight or priority_weight), which allows us to set a percentage value which can go above 100%. 100% = 1024, 200% = 2048, and so on. But I kinda also don't like the percentage suggestion.

At least, I'd like to set something like, this container has a share 1.4 times bigger than that other container which has the default 1. And the third container only 0.5 times the share - and so on. So, some dotted relative weightings at least.

[dionysius]

Looks like this request missed 4.0, any plans when at least some sort of decision will be made on that? I understand with support of VM's the scope got probably a bit more complex.