Hi Luca,

Thanks for the reply.  I couldn't get the errno anymore... Sorry for
the confusion!  The minimal main in appendix B runs well for me too.

Btw, rt-tests released today still have the bug.

I have a question about the admission test with cpuset.  Is the
sched_deadline admission test examined with respect to the CPUs
allowed in the cpuset?
I get deterministic admission test result without cpuset.  m-1 cores
can be utilized (not m?).
But with cpuset, the total utilization of accepted sched_deadline
tasks seems not respecting the cpuset and changes every run.  For
example, if cpuset contains 4 cores, I can have task sets (bound to
this cpuset) utilizing 400%, 600%, or 300% before failing to add
another task. It could be my program's issue. I'm still looking into
it.

Thanks,
Ming

On Thu, Jun 20, 2019 at 2:02 PM Luca Abeni [off-list ref] wrote:

Hi,

On Thu, 20 Jun 2019 at 22:25, Ming Yang [off-list ref] wrote:

quoted

Hi,

sched_setattr for SCHED_DEADLINE fails if it is called after setting
cpuset that doesn't include all CPUs. The sched_deadline document
states that cgroup/cpuset should be used for task affinity.  But I got
errno EPERM when calling sched_setattr, after setting cpuset.

Which kernel are you using? I just tried on 5.0.0 (actually, it is
Ubuntu's 5.0.0-17-lowlatency) and it worked.
I followed the cpuset instructions from the documentation (except for
not mounting the cpuset fs: Ubuntu already mounted it for me), and the
"Minimal main()" from Appendix B of the document.
The SCHED_DEADLINE thread runs correctly, with the specified runtime
and period, and is affine to CPU 0 only.

What did you exactly do, to get the failure?

quoted

Section 5.1 example in sched_deadline document is broken. Not only
rt-app doesn't run in the way shown in the example anymore, but also
other sched_deadline program fails.

Yes, rt-app behaviour changed... But other SCHED_DEADLINE programs
(for example, the program from Appendix B) seem to work correctly.

quoted

rt-tests deadline_test.c illustrated a working way to use cpuset for
sched_deadline tasks.  It sets cpuset *after* sched_setattr
(https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/sched_deadline/deadline_test.c?h=unstable/devel/latest).
I suppose this is the only way to assign CPUs for sched_dealine tasks
now.

I suspect this is actually a bug... Juri had a patchset to fix it, if
I remember correctly.

quoted

Can anyone please explain why sched_setattr fails after setting
cpuset?

It does not fail here... Maybe this is a bug introduced after 5.0.0,
or maybe there is some other difference between your setup an my one.


Luca

quoted

 Does the sched_deadline scheduler rejects both affinity mask
and cpuset now?
Does this mean admission test always assume all CPUs and no admission
test would be examined when setting the cpuset of the task?

Thanks,
Ming