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 <lucabe72@xxxxxxxxx> wrote: > > 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
