Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

[孙世龙 sunshilong]

Hi, list

Are there some methods that could limit how much CPU resources could
be maximally
used by a single Xenomai process or thread?
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.

RE: Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

[Meng, Fino]

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
>thread?
>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.

Re: Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

[孙世龙 sunshilong]

Hi, 孟祥夫
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?

Best Regards.
sunshilong(孙世龙)

On Fri, Jul 17, 2020 at 8:55 AM Meng, Fino <fino.meng@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
> >thread?
> >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.
>

RE: Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

[Meng, Fino]

>Sent: Friday, July 17, 2020 6:18 PM
>
>Hi, 孟祥夫
>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?

Hi Shilong,

What I am thinking, instead of use passive mechanism(cgroup, schd_tp...),  
how about let RT thread finish workload in time and voluntary give out CPU?
More complex design will induce more issue until out of control, 

BR/Fino

>
>Best Regards.
>sunshilong(孙世龙)
>
>On Fri, Jul 17, 2020 at 8:55 AM Meng, Fino <fino.meng@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 thread?
>> >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.
>>

RE: Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

[Lange Norbert]

Hello,

I am reconnecting the ML.


I am not aware of any good documentation for SCHED_TP,
but there is an example in smokey/sched-tp which Id use as starting point.

I don’t think SCHED_TP will measurable affect latency, outside of course in
the case where its “by design” (process needs to wait for its timeslice).

Norbert

From: 孙世龙 sunshilong <sunshilong369@gmail.com>
Sent: Samstag, 18. Juli 2020 07:51
To: Lange Norbert <norbert.lange@andritz.com>
Cc: Meng, Fino <fino.meng@intel.com>
Subject: Re: Are there some methods that could limit how much CPU resources could be a single Xenomai process or thread?

Hi, Norbert

Thank you for the clarification.

>You can do something similar with the  temporal partitioning scheduler (SCHED_TP),
>cgroups uses a similar concept of "time-slices", but is less strict AFAIU
Does SCHED_TP enlarge the latency(compared to SCHED_FIFO)?

Do you have more information about SCHED_TP?  If the answer is yes,
could you please suggest some documents for me to go through?

I searched all the source code of the Xenomai project and checked
the help information from the Kconfig, but no useful information about
SCHED_TP was found.
I googled it, only found this:
The SCHED_TP policy divides the scheduling time into a recurring
global frame, which is itself divided into an arbitrary number of time
partitions. Only threads assigned to the current partition are deemed
runnable, and scheduled according to a FIFO-based rule within this
partition. When completed, the current partition is advanced
automatically to the next one by the scheduler, and the global time
frame recurs from the first partition defined, when the last partition
has ended.

Thank you for your attention to this matter.
Best Regards.
Sunshilong(孙世龙)
On Fri, Jul 17, 2020 at 6:44 PM Lange Norbert <norbert.lange@andritz.com<mailto:norbert.lange@andritz.com>> wrote:


> -----Original Message-----
> From: Xenomai <xenomai-bounces@xenomai.org<mailto:xenomai-bounces@xenomai.org>> On Behalf Of ???
> sunshilong via Xenomai
> Sent: Freitag, 17. Juli 2020 12:18
> To: Meng, Fino <fino.meng@intel.com<mailto:fino.meng@intel.com>>
> Cc: Xenomai (xenomai@xenomai.org<mailto:xenomai@xenomai.org>) <xenomai@xenomai.org<mailto:xenomai@xenomai.org>>
> Subject: Re: Are there some methods that could limit how much CPU
> resources could be a single Xenomai process or thread?
>
> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR
> ATTACHMENTS.
>
>
> Hi, 孟祥夫
> 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.

You can do something similar with the  temporal partitioning scheduler (SCHED_TP),
cgroups uses a similar concept of "time-slices", but is less strict AFAIU

Norbert

________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________