lkml.org 
[lkml]   [2019]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC V2 0/2] sched/fair: Fallback to sched-idle CPU for better performance
On 25-04-19, 15:07, Viresh Kumar wrote:
> Hi,
>
> Here is another attempt to get some benefit out of the sched-idle
> policy. The previous version [1] focused on getting better power numbers
> and this version tries to get better performance or lower response time
> for the tasks.
>
> The first patch is unchanged from v1 and accumulates
> information about sched-idle tasks per CPU.
>
> The second patch changes the way the target CPU is selected in the fast
> path. Currently, we target for an idle CPU in select_idle_sibling() to
> run the next task, but in case we don't find idle CPUs it is better to
> pick a CPU which will run the task the soonest, for performance reason.
> A CPU which isn't idle but has only SCHED_IDLE activity queued on it
> should be a good target based on this criteria as any normal fair task
> will most likely preempt the currently running SCHED_IDLE task
> immediately. In fact, choosing a SCHED_IDLE CPU shall give better
> results as it should be able to run the task sooner than an idle CPU
> (which requires to be woken up from an idle state).
>
> Basic testing is done with the help of rt-app currently to make sure the
> task is getting placed correctly.

More results here:

- Tested on Octacore Hikey platform (all CPUs change frequency
together).

- rt-app json attached here. It creates few tasks and we monitor the
scheduling latency for them by looking at "wu_lat" field (usec).

- The histograms are created using
https://github.com/adkein/textogram: textogram -a 0 -z 1000 -n 10

- the stats are accumulated using: https://github.com/nferraz/st

- NOTE: The % values shown don't add up, just look at total numbers
instead


Test 1: Create 8 CFS tasks (no SCHED_IDLE tasks) without this
patchset:

0 - 100 : ################################################## 72% (3688)
100 - 200 : ################ 24% (1253)
200 - 300 : ## 2% (149)
300 - 400 : 0% (22)
400 - 500 : 0% (1)
500 - 600 : 0% (3)
600 - 700 : 0% (1)
700 - 800 : 0% (1)
800 - 900 :
900 - 1000 : 0% (1)
>1000 : 0% (17)

N min max sum mean stddev
5136 0 2452 535985 104.358 104.585


Test 2: Create 8 CFS tasks and 5 SCHED_IDLE tasks:

A. Without sched-idle patchset:

0 - 100 : ################################################## 88% (3102)
100 - 200 : ## 4% (148)
200 - 300 : 1% (41)
300 - 400 : 0% (27)
400 - 500 : 0% (33)
500 - 600 : 0% (32)
600 - 700 : 1% (36)
700 - 800 : 0% (27)
800 - 900 : 0% (19)
900 - 1000 : 0% (26)
>1000 : 34% (1218)

N min max sum mean stddev
4710 0 67664 5.25956e+06 1116.68 2315.09


B. With sched-idle patchset:

0 - 100 : ################################################## 99% (5042)
100 - 200 : 0% (8)
200 - 300 :
300 - 400 :
400 - 500 : 0% (2)
500 - 600 : 0% (1)
600 - 700 :
700 - 800 : 0% (1)
800 - 900 : 0% (1)
900 - 1000 :
>1000 : 0% (40)

N min max sum mean stddev
5095 0 7773 523170 102.683 475.482


The mean latency dropped to 10% and the stddev to around 25% with this
patchset.

I have tried more combinations of CFS and SCHED_IDLE tasks and see
expected improvement in scheduling latency for all of them.

--
viresh
[unhandled content-type:application/json]
\
 
 \ /
  Last update: 2019-05-15 13:57    [W:0.083 / U:3.720 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site