Re: [RFC PATCH v3 00/16] Core scheduling v3

From: Tim Chen
Date: Mon Aug 05 2019 - 11:55:32 EST


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