linux-kernel - RE: sched/fair: scheduler not running high priority process on idle cpu

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] [day] [month] [year] [list]

Message-ID: <512f01b3e4cd4c3fa26ce767466fec21@AcuMS.aculab.com>
Date:   Mon, 20 Jan 2020 10:51:07 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Dietmar Eggemann' <dietmar.eggemann@....com>,
        'Steven Rostedt' <rostedt@...dmis.org>
CC:     'Vincent Guittot' <vincent.guittot@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: sched/fair: scheduler not running high priority process on idle
 cpu

From: Dietmar Eggemann
> Sent: 20 January 2020 09:39
..
> > I guess this only 'gives away' extra RT processes.
> > Rather than 'stealing' them - which is what I need.
> 
> Isn't part of the problem that RT doesn't maintain
> cp->pri_to_cpu[CPUPRI_IDLE] (CPUPRI_IDLE = 0).
> 
> So push/pull (find_lowest_rq()) never returns a mask of idle CPUs.
> 
> There was
> https://lore.kernel.org/r/1415260327-30465-2-git-send-email-pang.xunlei@linaro.org
> in 2014 but it didn't go mainline.
> 
> There was a similar question in Nov last year:
> 
> https://lore.kernel.org/r/CH2PR19MB3896AFE1D13AD88A17160860FC700@CH2PR19MB3896.namprd19.prod.outlook.com

They are probably all related.
My brain doesn't have space to completely 'grok' the scheduler without something
else being pushed out of the main cache.

I bet there are other cases where it decides to run a process on a cpu that
is running a process that is bound to that cpu while there are other idle cpu.

Partially because the problem is 'hard', getting it anywhere near 'right'
for NUMA systems with lots of cpus without using all the processing
power just deciding what to run is probably impossible.
However faster decisions can probably be made with 'slightly stale' data that
get corrected later if they are incorrect.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)