linux-kernel - Re: [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor

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: <383e33a0-bace-a387-b47e-30fbec4f18db@redhat.com>
Date:   Fri, 7 Aug 2020 13:30:32 +0200
From:   Daniel Bristot de Oliveira <bristot@...hat.com>
To:     peterz@...radead.org, Juri Lelli <juri.lelli@...hat.com>
Cc:     mingo@...hat.com, rostedt@...dmis.org, tglx@...utronix.de,
        linux-kernel@...r.kernel.org, luca.abeni@...tannapisa.it,
        tommaso.cucinotta@...tannapisa.it, alessio.balsini@...il.com,
        dietmar.eggemann@....com, linux-rt-users@...r.kernel.org,
        mtosatti@...hat.com, williams@...hat.com,
        valentin.schneider@....com
Subject: Re: [RFC PATCH v2 6/6] sched/fair: Implement starvation monitor

On 8/7/20 12:46 PM, peterz@...radead.org wrote:
> On Fri, Aug 07, 2020 at 11:56:04AM +0200, Juri Lelli wrote:
>> Starting deadline server for lower priority classes right away when
>> first task is enqueued might break guarantees, as tasks belonging to
>> intermediate priority classes could be uselessly preempted. E.g., a well
>> behaving (non hog) FIFO task can be preempted by NORMAL tasks even if
>> there are still CPU cycles available for NORMAL tasks to run, as they'll
>> be running inside the fair deadline server for some period of time.
>>
>> To prevent this issue, implement a starvation monitor mechanism that
>> starts the deadline server only if a (fair in this case) task hasn't
>> been scheduled for some interval of time after it has been enqueued.
>> Use pick/put functions to manage starvation monitor status.
> One thing I considerd was scheduling this as a least-laxity entity --
> such that it runs late, not early -- and start the server when
> rq->nr_running != rq->cfs.h_nr_running, IOW when there's !fair tasks
> around.
> 
> Not saying we should do it like that, but that's perhaps more
> deterministic than this.
> 

I agree, what we want here is something that schedules the server if it still
retains some runtime when the laxity is 0. But this is easier said than done, as
this would require another scheduler (other pros and cons and analysis (and
hours of work)...).

But, for the starvation monitor purpose, the goal is not (necessarily) to
provide a deterministic guarantee for the starving task, but to avoid system
issues while minimizing the damage to the "real" real-time workload. With that
in mind, we could relax our ambitions...

Thoughts?

-- Daniel