Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?
sunshilong369 at gmail.com
Fri Jul 17 12:18:21 CEST 2020
Thank you for taking the time to respond to my question.
>In my understanding cgroup's design is exclusionary with real-time/deterministic/time coordinate design.
>The latency/jitter is already down to 20us level, how it can endure cgroup's volatility.
I don't hold much hope, either. But I am not sure whether it's
impossible to achieve this goal or not.
>Do u really have strong requirement for this scenario?
It's a strong requirement, but not necessary.
>Maybe it will work on a highly fine-tuned environment.
Any advice on how to proceed?
On Fri, Jul 17, 2020 at 8:55 AM Meng, Fino <fino.meng at intel.com> wrote:
> In my understanding cgroup's design is exclusionary with real-time/deterministic/time coordinate design,
> The latency/jitter is already down to 20us level, how it can endure cgroup's volatility,
> Do u really have strong requirement for this scenario? maybe it will work on a highly fine-tuned environment.
> BR / Fino (孟祥夫)
> Intel – IOTG Developer Enabling
> >Sent: Thursday, July 16, 2020 8:01 PM
> >Hi, list
> >Are there some methods that could limit how much CPU resources could be maximally used by a single Xenomai process or
> >Does the Linux kernel's cgroup interface work for the Xenomai?
> >The description about cgroup quoted from the Linux program manual:
> >The kernel's cgroup interface is provided through a pseudo-filesystem called cgroupfs.
> >Grouping is implemented in the core cgroup kernel code, while resource tracking and limits are implemented in a set of per-
> >resource-type subsystems (memory, CPU, and so on).
> >Thank you for your attention to this matter.
> >Looking forward to hearing from you.
> >Best Regards.
More information about the Xenomai