lkml.org 
[lkml]   [2019]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH v3 00/16] Core scheduling v3
Date
On 8/2/19 8:37 AM, Julien Desfossez wrote:
> We tested both Aaron's and Tim's patches and here are our results.
>
> Test setup:
> - 2 1-thread sysbench, one running the cpu benchmark, the other one the
> mem benchmark
> - both started at the same time
> - both are pinned on the same core (2 hardware threads)
> - 10 30-seconds runs
> - test script: https://paste.debian.net/plainh/834cf45c
> - only showing the CPU events/sec (higher is better)
> - tested 4 tag configurations:
> - no tag
> - sysbench mem untagged, sysbench cpu tagged
> - sysbench mem tagged, sysbench cpu untagged
> - both tagged with a different tag
> - "Alone" is the sysbench CPU running alone on the core, no tag
> - "nosmt" is both sysbench pinned on the same hardware thread, no tag
> - "Tim's full patchset + sched" is an experiment with Tim's patchset
> combined with Aaron's "hack patch" to get rid of the remaining deep
> idle cases
> - In all test cases, both tasks can run simultaneously (which was not
> the case without those patches), but the standard deviation is a
> pretty good indicator of the fairness/consistency.

Thanks for testing the patches and giving such detailed data.

I came to realize that for my scheme, the accumulated deficit of forced idle could be wiped
out in one execution of a task on the forced idle cpu, with the update of the min_vruntime,
even if the execution time could be far less than the accumulated deficit.
That's probably one reason my scheme didn't achieve fairness.

Tim

\
 
 \ /
  Last update: 2019-08-05 17:57    [W:0.158 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site