linux-kernel - Re: [PATCH 3/4] sched/deadline: Make DL capacity-aware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200415184203.50862783@sweethome>
Date:   Wed, 15 Apr 2020 18:42:03 +0200
From:   luca abeni <luca.abeni@...tannapisa.it>
To:     Juri Lelli <juri.lelli@...hat.com>
Cc:     Dietmar Eggemann <dietmar.eggemann@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Wei Wang <wvw@...gle.com>, Quentin Perret <qperret@...gle.com>,
        Alessio Balsini <balsini@...gle.com>,
        Pavan Kondeti <pkondeti@...eaurora.org>,
        Patrick Bellasi <patrick.bellasi@...bug.net>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Valentin Schneider <valentin.schneider@....com>,
        Qais Yousef <qais.yousef@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] sched/deadline: Make DL capacity-aware

Hi Juri,

On Wed, 15 Apr 2020 15:20:04 +0200
Juri Lelli <juri.lelli@...hat.com> wrote:
[...]
> > > I'm thinking that, while dl_task_fits_capacity() works well when
> > > selecting idle cpus, in this case we should consider the fact
> > > that curr might be deadline as well and already consuming some of
> > > the rq capacity.
> > > 
> > > Do you think we should try to take that into account, maybe using
> > > dl_rq->this_bw ?  
> > 
> > So you're saying that cpudl_find(..., later_mask) could return 1 (w/
> > best_cpu (cp->elements[0].cpu) in later_mask).
> > 
> > And that this best_cpu could be a non-fitting CPU for p.
> > 
> > This could happen if cp->free_cpus is empty (no idle CPUs) so we
> > take cpudl_find()'s else path and in case p's deadline <
> > cp->elements[0] deadline.
> > 
> > We could condition the 'return 1' on best_cpu fitting p.
> > 
> > But should we do this for cpudl_find(..., NULL) calls from
> > check_preempt_equal_dl() as well or will this break GEDF?  
> 
> So, even by not returning best_cpu, as above, if it doesn't fit p's bw
> requirement, I think we would be breaking GEDF, which however doesn't
> take asym capacities into account.

Well, gEDF could take asymmetric capacities into account by scheduling
the earliest deadline task on the fastest CPU (and the task with the
second earliest deadline on the second fastest CPU, and so on...)

But this could cause a lot of unneeded migrations (I tried to discuss
this issue in a previous OSPM presentation). My original approach to
work around this issue was to schedule a task on the slowest core on
which the task can fit (some experiments revealed that this heuristic
can approximate the gEDF behaviour without causing too many
migrations)... But this patch is not included on the current patchset,
and will be proposed later, after the most important patches have been
merged.


> OTOH, if we let p migrate to a cpu
> that can't suit it, it will still be missing its deadlines (plus it
> would be causing deadline misses on the task that was running on
> best_cpu).

In theory, if the task is scheduled on a core that is too slow for it
then we must allow faster cores to pull it later (when tasks with
earlier deadlines block). But this might be problematic, because it can
require to migrate a currently scheduled task.


			Luca

> 
> check_preempt_equal_dl() worries me less, as it is there to service
> corner cases (hopefully not so frequent).
>