Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1720403

Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

From Mathieu Poirier <mathieu.poirier@linaro.org>
Newsgroups linux.kernel
Subject Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting
Date 2017-08-25 22:40 +0200
Message-ID <uityx-hl-5@gated-at.bofh.it> (permalink)
References (2 earlier) <uhJP4-4Ik-9@gated-at.bofh.it> <uhVdw-3Ah-13@gated-at.bofh.it> <ui750-2Q6-13@gated-at.bofh.it> <uifYC-nL-7@gated-at.bofh.it> <uijzc-2pd-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 25 August 2017 at 03:52, Luca Abeni <luca.abeni@santannapisa.it> wrote:
> On Fri, 25 Aug 2017 08:02:43 +0200
> luca abeni <luca.abeni@santannapisa.it> wrote:
> [...]
>> > The above demonstrate that even if we have two CPUsets new task belong
>> > to the "default" CPUset and as such can use all the available CPUs.
>>
>> I still have a doubt (probably showing all my ignorance about
>> CPUsets :)... In this situation, we have 3 CPUsets: "default",
>> set1, and set2... Is everyone of these CPUsets associated to a
>> root domain (so, we have 3 root domains)? Or only set1 and set2 are
>> associated to a root domain?
>
> Ok, after reading (and hopefully understanding better :) the code, I
> think this question was kind of silly... There are only 2 root domains,
> corresponding to set1 and set2 (right?).

For this scenario yes, you are correct.

>
> [...]
>
>> > So above we'd run the acceptance test on root
>> > domain A and B before promoting the task.  Of course we'd also have to
>> > add the utilisation of that task to both root domain.  Although simple
>> > it goes at the core of the DL scheduler and touches pretty much every
>> > aspect of it, something I'm reluctant to embark on.
>>
>> I see... So, the "default" CPUset does not have any root domain
>> associated to it? If it had, we could just subtract the maximum
>> utilizations of set1 and set2 to it when creating the root domains of
>> set1 and set2.
> ...
> So, this idea of mine had no sense.
>
> I think the correct solution is what you implemented in your patchset
> (if I understand it correctly).
>
> If we want to have task spanning multiple root domains, many more
> changes in the code are needed... I am wondering if it would make more
> sense to track utilizations per runqueue (instead of per root domain):
> - when a task tries to become SCHED_DEADLINE, we count how many CPUs are
>   in its affinity mask. Let's call "n" this number
> - then, we sum u / n (where "u" is the task's utilization) to the
>   utilization of every runqueue that is in its affinity mask, and we
>   check if all the sums are below the schedulability bound
>
> For tasks spanning one single root domain, this should be equivalent to
> the current admission test. Moreover, this check should ensure that no
> root domain can be ever overloaded (even if tasks span multiple
> domains).
> But I do not know the locking implications for this idea... I suspect
> it will not scale :(
>
>
>
>                                 Luca

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting  Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-16 23:30 +0200
  [PATCH 5/7] cgroup: Concentrate DL related validation code in one place Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-16 23:30 +0200
  Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Luca Abeni <luca.abeni@santannapisa.it> - 2017-08-22 14:30 +0200
    Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-23 21:50 +0200
      Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Luca Abeni <luca.abeni@santannapisa.it> - 2017-08-24 10:00 +0200
        Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Juri Lelli <juri.lelli@arm.com> - 2017-08-24 10:40 +0200
        Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-24 22:40 +0200
          Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting luca abeni <luca.abeni@santannapisa.it> - 2017-08-25 08:10 +0200
            Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Luca Abeni <luca.abeni@santannapisa.it> - 2017-08-25 12:00 +0200
              Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-25 22:00 +0200
              Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-25 22:40 +0200
      Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Luca Abeni <luca.abeni@santannapisa.it> - 2017-08-25 16:40 +0200
        Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Mathieu Poirier <mathieu.poirier@linaro.org> - 2017-08-25 22:30 +0200

csiph-web