Hi, On Thu, 20 Jun 2019 at 22:25, Ming Yang <minos.future@xxxxxxxxx> wrote: > > 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? > 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. > > 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. > 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 > 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
