eas-dev

eas-dev@lists.linaro.org

396 discussions

Re: [Eas-dev] [RESEND PATCH v2] doc: measure the efficiency of cpufreq governors

by Amit Kucheria

(This might be of interest to folks on eas-dev, adding them to cc) On Wed, Jun 24, 2015 at 11:53 AM, Vincent Guittot <vincent.guittot(a)linaro.org> wrote: > On 24 June 2015 at 03:41, <pang.xunlei(a)zte.com.cn> wrote: >> Hi Vincent, >> >> Vincent Guittot <vincent.guittot(a)linaro.org> wrote 2015-06-23 PM 09:43:55: >>> Re: [RESEND PATCH v2] doc: measure the efficiency of cpufreq governors >>> >>> Hi Xunlei, >>> >>> I have run the bench on a quad A15 with sched-dvfs (but without eas >>> patches unlike you) >>> #sudo ./test.sh 4 100 1000 >>> Frequency domain CPU0~CPU3, run 100ms, sleep 1000ms: >>> powersave efficiency: 0% >>> performance efficiency: 100% >>> conservative efficiency: 18% >>> ondemand efficiency: 48% >>> cfs efficiency: 24% >>> >>> #sudo ./test.sh 4 200 1000 >>> Frequency domain CPU0~CPU3, run 200ms, sleep 1000ms: >>> powersave efficiency: 0% >>> performance efficiency: 100% >>> conservative efficiency: 40% >>> ondemand efficiency: 68% >>> cfs efficiency: 30% >>> >>> $ sudo ./test.sh 4 50 1000 >>> Frequency domain CPU0~CPU3, run 50ms, sleep 1000ms: >>> powersave efficiency: 0% >>> performance efficiency: 100% >>> conservative efficiency: 0% >>> ondemand efficiency: 25% >>> cfs efficiency: 19% >>> >>> As an example, here is the result when ondemand parameter are tuned >>> for the platform >>> sudo ./test.sh 4 100 1000 >>> Frequency domain CPU0~CPU3, run 100ms, sleep 1000ms: >>> powersave efficiency: 0% >>> performance efficiency: 100% >>> conservative efficiency: 19% >>> ondemand efficiency: 94% >>> cfs efficiency: 23% >>> >>> Beside these results, i have seen variation in the results that >>> confirm the interest of having more statistics like, min, man stdev >> >> I guess the hardware environment has something to do with this, on my >> platform, there're 11 available freuencies in total: 1200Mhz~2200Mhz, >> the step size is 100Mhz. > > Yes for sure, it was just to give some figures with a different platform. > Regarding the variation, i have seen these variations for the same > platform with the same SW. Nevertheless, this variations are somewhat > normal if we consider the default sampling rate of 164ms for some > governor compared to a run duration of 100ms > > Regards, > Vincent > >> >> Also it may get different results when running with different workload >> loops. >> >> -Xunlei >> >>> >>> Regards, >>> Vincent >>> >>> >>> >>> On 18 June 2015 at 13:35, <pang.xunlei(a)zte.com.cn> wrote: >>> > Just tested on my Intel EAS test environment(implemented x86 frequency >>> > invariant hook). >>> > With EAS disabled and sched-dvfs enabled. >>> > >>> > #./test.sh 3 100 1000 >>> > Frequency domain CPU0~CPU2, run 100ms, sleep 1000ms: >>> > powersave efficiency: 0% >>> > performance efficiency: 100% >>> > conservative efficiency: 92% >>> > ondemand efficiency: 97% >>> > cfs efficiency: 79% >>> > >>> > #./test.sh 3 200 1000 >>> > Frequency domain CPU0~CPU2, run 200ms, sleep 1000ms: >>> > powersave efficiency: 0% >>> > performance efficiency: 100% >>> > conservative efficiency: 97% >>> > ondemand efficiency: 99% >>> > cfs efficiency: 89% >>> > >>> > #./test.sh 3 50 1000 >>> > Frequency domain CPU0~CPU2, run 50ms, sleep 1000ms: >>> > powersave efficiency: 0% >>> > performance efficiency: 100% >>> > conservative efficiency: 93% >>> > ondemand efficiency: 96% >>> > cfs efficiency: 58% >>> > >>> > #./test.sh 3 1000 100 >>> > Frequency domain CPU0~CPU2, run 1000ms, sleep 100ms: >>> > powersave efficiency: 0% >>> > performance efficiency: 100% >>> > conservative efficiency: 99% >>> > ondemand efficiency: 99% >>> > cfs efficiency: 97% >>> > >>> > Seems sched-dvfs is computing inefficient at low cpu usage(implies >> power >>> > efficient), >>> > but computing efficient at high cpu usage. >>> > >>> > -Xunlei >>> > >>> > Xunlei Pang <xlpang(a)126.com> wrote 2015-06-18 PM 05:06:07: >>> >> [RESEND PATCH v2] doc: measure the efficiency of cpufreq governors >>> >> >>> >> From: Xunlei Pang <pang.xunlei(a)linaro.org> >>> >> >>> >> DVFS adds a latency in the execution of task because of the time to >>> >> decide to move at max freq. We need to measure this latency and check >>> >> that the governor stays in an acceptable range. >>> >> >>> >> When workgen runs a json file, a log file is created for each thread. >>> >> This log file records the number of loop that has been executed and >>> >> the duration for executing these loops (per phase). We can use these >>> >> figures to evaluate to latency that is added by a cpufreq governor >>> >> and its "performance efficiency". >>> >> >>> >> We use the run+sleep pattern to do the measurement, for the run time >> per >>> >> loop, the performance governor should run the expected duration as >> the >>> >> CPU stays a max freq. At the opposite, the powersave governor will >> give >>> >> use the longest duration (as it stays at lowest OPP). Other governor >>> > will >>> >> be somewhere between the 2 previous duration as they will use several >>> > OPP >>> >> and will go back to max frequency after a defined duration which >> depends >>> >> on its monitoring period. >>> >> >>> >> The formula: >>> >> >>> >> duration of powersave gov - duration of the gov >>> >> -------------------------------------------------------- x 100% >>> >> duration of powersave gov - duration of performance gov >>> >> >>> >> will give the efficiency of the governor. 100% means as efficient as >>> >> the perf governor and 0% means as efficient as the powersave >> governor. >>> >> >>> >> This patch offers json files and shell scripts to do the measurement, >>> >> >>> >> Usage: ./test.sh <cpus> <runtime> <sleeptime> >>> >> cpus: number of cpus in the CPU0's frequency domain >>> >> runtime: running time in ms per loop of the workload pattern >>> >> sleeptime: sleeping time in ms per loop of the workload pattern >>> >> >>> >> Example: >>> >> "./test.sh 4 100 1000" means >>> >> CPU0~CPU3 sharing frequency, "100ms run + 1000ms sleep" workload >>> > pattern. >>> >> >>> >> test result on my machine: >>> >> ~#./test.sh 4 100 1000 >>> >> Frequency domain CPU0~CPU3, run 100ms, sleep 1000ms: >>> >> powersave efficiency: 0% >>> >> performance efficiency: 100% >>> >> conservative efficiency: 28% >>> >> ondemand efficiency: 95% >>> >> >>> >> NOTE: Make sure there are "sed", "cut", "grep", "rt-app", etc tools >> on >>> >> your test machine, and run the script under root privilege. >>> >> >>> >> Signed-off-by: Xunlei Pang <pang.xunlei(a)linaro.org> >>> >> --- >>> >> doc/examples/cpufreq_governor_efficiency/README | 54 >> ++++++++++++++ >>> >> .../cpufreq_governor_efficiency/calibration.json | 27 +++++++ >>> >> .../cpufreq_governor_efficiency/calibration.sh | 11 +++ >>> >> doc/examples/cpufreq_governor_efficiency/dvfs.json | 27 +++++++ >>> >> doc/examples/cpufreq_governor_efficiency/dvfs.sh | 38 ++++++++++ >>> >> doc/examples/cpufreq_governor_efficiency/test.sh | 82 +++++++++++ >>> >> +++++++++++ >>> >> 6 files changed, 239 insertions(+) >>> >> create mode 100644 doc/examples/cpufreq_governor_efficiency/README >>> >> create mode 100644 >>> > doc/examples/cpufreq_governor_efficiency/calibration.json >>> >> create mode 100755 >>> > doc/examples/cpufreq_governor_efficiency/calibration.sh >>> >> create mode 100644 >> doc/examples/cpufreq_governor_efficiency/dvfs.json >>> >> create mode 100755 doc/examples/cpufreq_governor_efficiency/dvfs.sh >>> >> create mode 100755 doc/examples/cpufreq_governor_efficiency/test.sh >>> >> >>> >> diff --git a/doc/examples/cpufreq_governor_efficiency/README b/doc/ >>> >> examples/cpufreq_governor_efficiency/README >>> >> new file mode 100644 >>> >> index 0000000..cc8efe1 >>> >> --- /dev/null >>> >> +++ b/doc/examples/cpufreq_governor_efficiency/README >>> >> @@ -0,0 +1,54 @@ >>> >> +Measure the efficiency of cpufreq governors using rt-app >>> >> + >>> >> +BACKGROUND: >>> >> + DVFS adds a latency in the execution of task because of the time >> to >>> >> + decide to move at max freq. We need to measure this latency and >>> > check >>> >> + that the governor stays in an acceptable range. >>> >> + >>> >> + When workgen runs a json file, a log file is created for each >>> > thread. >>> >> + This log file records the number of loop that has been executed >> and >>> >> + the duration for executing these loops (per phase). We can use >>> > these >>> >> + figures to evaluate to latency that is added by a cpufreq >> governor >>> >> + and its "performance efficiency". >>> >> + >>> >> + We use the run+sleep pattern to do the measurement, for the run >>> > time per >>> >> + loop, the performance governor should run the expected duration >> as >>> > the >>> >> + CPU stays a max freq. At the opposite, the powersave governor >> will >>> > give >>> >> + use the longest duration (as it stays at lowest OPP). Other >>> > governor will >>> >> + be somewhere between the 2 previous duration as they will use >>> > several OPP >>> >> + and will go back to max frequency after a defined duration which >>> > depends >>> >> + on its monitoring period. >>> >> + >>> >> + The formula: >>> >> + >>> >> + duration of powersave gov - duration of the gov >>> >> + -------------------------------------------------------- x 100% >>> >> + duration of powersave gov - duration of performance gov >>> >> + >>> >> + will give the efficiency of the governor. 100% means as >> efficient >>> > as >>> >> + the perf governor and 0% means as efficient as the powersave >>> > governor. >>> >> + >>> >> + This test offers json files and shell scripts to do the >>> > measurement, >>> >> + >>> >> +USAGE: >>> >> + ./test.sh <cpus> <runtime> <sleeptime> >>> >> + cpus: number of cpus in the CPU0's frequency domain >>> >> + runtime: running time in ms per loop of the workload pattern >>> >> + sleeptime: sleeping time in ms per loop of the workload pattern >>> >> + >>> >> +Example: >>> >> + "./test.sh 4 100 1000" means >>> >> + CPU0~CPU3 sharing frequency, "100ms run + 1000ms sleep" workload >>> > pattern. >>> >> + >>> >> + test result on an Intel machine: >>> >> + ~#./test.sh 4 100 1000 >>> >> + Frequency domain CPU0~CPU3, run 100ms, sleep 1000ms: >>> >> + powersave efficiency: 0% >>> >> + performance efficiency: 100% >>> >> + conservative efficiency: 28% >>> >> + ondemand efficiency: 95% >>> >> + >>> >> +NOTE: >>> >> + Make sure there are "sed", "cut", "grep", "rt-app", etc tools >>> >> on your test >>> >> + machine, and run the script under root privilege. >>> >> + >>> >> diff --git a/doc/examples/cpufreq_governor_efficiency/ >>> >> calibration.json >>> > b/doc/examples/cpufreq_governor_efficiency/calibration.json >>> >> new file mode 100644 >>> >> index 0000000..4377990 >>> >> --- /dev/null >>> >> +++ b/doc/examples/cpufreq_governor_efficiency/calibration.json >>> >> @@ -0,0 +1,27 @@ >>> >> +{ >>> >> + "tasks" : { >>> >> + "thread" : { >>> >> + "instance" : 1, >>> >> + "cpus" : [0], >>> >> + "loop" : 1, >>> >> + "phases" : { >>> >> + "run" : { >>> >> + "loop" : 1, >>> >> + "run" : 200000, >>> >> + }, >>> >> + "sleep" : { >>> >> + "loop" : 1, >>> >> + "sleep" : 200000, >>> >> + } >>> >> + } >>> >> + } >>> >> + }, >>> >> + "global" : { >>> >> + "default_policy" : "SCHED_FIFO", >>> >> + "calibration" : "CPU0", >>> >> + "lock_pages" : true, >>> >> + "ftrace" : true, >>> >> + "logdir" : "./", >>> >> + } >>> >> +} >>> >> + >>> >> diff --git a/doc/examples/cpufreq_governor_efficiency/calibration.sh >>> >> b/doc/examples/cpufreq_governor_efficiency/calibration.sh >>> >> new file mode 100755 >>> >> index 0000000..d10e644 >>> >> --- /dev/null >>> >> +++ b/doc/examples/cpufreq_governor_efficiency/calibration.sh >>> >> @@ -0,0 +1,11 @@ >>> >> +#!/bin/sh >>> >> + >>> >> +set -e >>> >> + >>> >> +echo performance > >>> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor >>> >> + >>> >> +sleep 1 >>> >> + >>> >> +pLoad=$(rt-app calibration.json 2>&1 |grep pLoad |sed 's/.*= >>> > $.*$ns.*/\1/') >>> >> +sed 's/"calibration" : .*,/"calibration" : '$pLoad',/' -i dvfs.json >>> >> + >>> >> diff --git a/doc/examples/cpufreq_governor_efficiency/dvfs.json b/ >>> >> doc/examples/cpufreq_governor_efficiency/dvfs.json >>> >> new file mode 100644 >>> >> index 0000000..b413156 >>> >> --- /dev/null >>> >> +++ b/doc/examples/cpufreq_governor_efficiency/dvfs.json >>> >> @@ -0,0 +1,27 @@ >>> >> +{ >>> >> + "tasks" : { >>> >> + "thread" : { >>> >> + "instance" : 1, >>> >> + "cpus" : [0], >>> >> + "loop" : 5, >>> >> + "phases" : { >>> >> + "running" : { >>> >> + "loop" : 1, >>> >> + "run" : 100000, >>> >> + }, >>> >> + "sleeping" : { >>> >> + "loop" : 1, >>> >> + "sleep" : 1000000, >>> >> + } >>> >> + } >>> >> + } >>> >> + }, >>> >> + "global" : { >>> >> + "default_policy" : "SCHED_OTHER", >>> >> + "calibration" : 90, >>> >> + "lock_pages" : true, >>> >> + "ftrace" : true, >>> >> + "logdir" : "./", >>> >> + } >>> >> +} >>> >> + >>> >> diff --git a/doc/examples/cpufreq_governor_efficiency/dvfs.sh b/doc/ >>> >> examples/cpufreq_governor_efficiency/dvfs.sh >>> >> new file mode 100755 >>> >> index 0000000..8591fc7 >>> >> --- /dev/null >>> >> +++ b/doc/examples/cpufreq_governor_efficiency/dvfs.sh >>> >> @@ -0,0 +1,38 @@ >>> >> +#!/bin/sh >>> >> + >>> >> +#echo $1 $2 $3 >>> >> +set -e >>> >> + >>> >> +if [ $1 ] && [ $2 ] ; then >>> >> + for i in $(seq 0 1 $(expr $2 - 1)); do >>> >> + echo $1 > >> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor >>> >> + #cat /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor >>> >> + done >>> >> + >>> >> + sleep 3 >>> >> +fi >>> >> + >>> >> +if [ $3 ] ; then >>> >> + sed 's/"run" : .*,/"run" : '$3',/' -i dvfs.json >>> >> +fi >>> >> + >>> >> +if [ $4 ] ; then >>> >> + sed 's/"sleep" : .*,/"sleep" : '$4',/' -i dvfs.json >>> >> +fi >>> >> + >>> >> +#cat dvfs.json >>> >> + >>> >> +rt-app dvfs.json 2> /dev/null >>> >> + >>> >> +if [ $1 ] ; then >>> >> + mv -f rt-app-thread-0.log rt-app_$1_run$3us_sleep$4us.log >>> >> + >>> >> + sum=0 >>> >> + for i in $(cat rt-app_$1_run$3us_sleep$4us.log | sed 'n;d' | sed >>> >> '1d' |cut -f 3); do >>> >> + sum=$(expr $sum + $i) >>> >> + done >>> >> + sum=$(expr $sum / 5) >>> >> + echo $sum >>> >> + rm -f rt-app_$1_run$3us_sleep$4us.log >>> >> +fi >>> >> + >>> >> diff --git a/doc/examples/cpufreq_governor_efficiency/test.sh b/doc/ >>> >> examples/cpufreq_governor_efficiency/test.sh >>> >> new file mode 100755 >>> >> index 0000000..d72fc6a >>> >> --- /dev/null >>> >> +++ b/doc/examples/cpufreq_governor_efficiency/test.sh >>> >> @@ -0,0 +1,82 @@ >>> >> +#!/bin/sh >>> >> + >>> >> +set -e >>> >> + >>> >> +set_calibration() { >>> >> + calibration.sh >>> >> +} >>> >> + >>> >> +test_efficiency() { >>> >> + >>> >> + FILENAME="results_$RANDOM$$.txt" >>> >> + >>> >> + if [ -e /sys/devices/system/cpu/cpu0/cpufreq/ >>> >> scaling_available_governors ]; then >>> >> + for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/ >>> >> scaling_available_governors); do >>> >> + export gov_$i=$(echo $i) >>> >> + done >>> >> + else >>> >> + echo "cpufreq is not available!" >>> >> + exit >>> >> + fi >>> >> + >>> >> + if [ ! $gov_performance ] ; then >>> >> + echo "Can't find performance governor!" >>> >> + exit >>> >> + fi >>> >> + >>> >> + if [ ! $gov_powersave ] ; then >>> >> + echo "Can't find powersave governor!" >>> >> + exit >>> >> + fi >>> >> + >>> >> + # Get powersave data >>> >> + dvfs.sh powersave $1 $2 $3 > $FILENAME >>> >> + powersave=$(cat $FILENAME |sed -n '1p') >>> >> + >>> >> + # Get performance data >>> >> + dvfs.sh performance $1 $2 $3 > $FILENAME >>> >> + performance=$(cat $FILENAME |sed -n '1p') >>> >> + >>> >> + if [ $performance -ge $powersave ] ; then >>> >> + echo "Error! Probably not input all the cpus in the same >>> >> frequency domain" >>> >> + exit >>> >> + fi >>> >> + >>> >> + denominator=$(expr $powersave - $performance) >>> >> + echo "powersave efficiency: 0%" >>> >> + echo "performance efficiency: 100%" >>> >> + >>> >> + # Calcuate other governors data >>> >> + for gov_next in $gov_conservative $gov_ondemand $gov_cfs; do >>> >> + if [ "$gov_next" != "" ] ; then >>> >> + dvfs.sh $gov_next $1 $2 $3 > $FILENAME >>> >> + data=$(cat $FILENAME |sed -n '1p'); >>> >> + numerator=$(expr $powersave - $data) >>> >> + numerator=$(expr $numerator \* 100) >>> >> + if [ $numerator -lt 0 ] ; then >>> >> + let numerator=0 >>> >> + fi >>> >> + data=$(expr $numerator / $denominator) >>> >> + echo "$gov_next efficiency: $data%" >>> >> + fi >>> >> + done >>> >> + >>> >> + rm -f $FILENAME >>> >> +} >>> >> + >>> >> +if [ $# -lt 3 ]; then >>> >> + echo "Usage: ./test.sh <cpus> <runtime> <sleeptime>" >>> >> + echo "cpus: number of cpus in the CPU0's frequency domain" >>> >> + echo "runtime: running time in ms per loop of the workload >> pattern" >>> >> + echo "sleeptime: sleeping time in ms per loop of the workload >>> > pattern" >>> >> + echo -e "\nExample: \n\"./test.sh 4 100 1000\" means\nCPU0~CPU3 >>> >> sharing frequency, \"100ms run + 1000ms sleep\" workload pattern.\n" >>> >> + exit >>> >> +fi >>> >> + >>> >> +echo "Frequency domain CPU0~CPU$(expr $1 - 1), run $2ms, sleep >> $3ms:" >>> >> + >>> >> +sleep 1 >>> >> +PATH=$PATH:. >>> >> +set_calibration >>> >> +test_efficiency $1 $(expr $2 \* 1000) $(expr $3 \* 1000) >>> >> + >>> >> -- >>> >> 1.9.1 >>> >>

11 years, 2 months

eas-test branch ci failed

by Alex Shi

Hi Fathi, I just updated the eas-test branch on https://git.linaro.org/kernel/eas-backports.git But the dashboard said deploy linaro kernel failed: https://validation.linaro.org/dashboard/streams/public/team/linaro/eas/bund… And I didn't find the eas on https://ci.linaro.org/view/kernel-ci/ or lsk-ci. Guess I miss sth, could you lead me to right ci or testing url? Thanks&Regards! Alex

11 years, 3 months

Updates to cpu capacity consolidation patches in the backports tree

by Amit Kucheria

Hi Alex, In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu capacity consolidation were merged. It would be a good idea to refresh the eas-backport tree so that these patches are cherry-picked directly from mainline into stable/sched-upstream branch and their equivalent versions in stable/sched-core are removed. Regards, Amit

11 years, 3 months

[RFC internal v2 0/4] scheduler-based cpu frequency scaling

by Michael Turquette

11 years, 4 months

[PATCH 0/4] scheduler-based cpu frequency scaling

by Michael Turquette

This series implements an event-driven cpufreq governor that scales cpu frequency as a function of cfs runqueue utilization. The intent of this RFC is to get some discussion going about how the scheduler can become the policy engine for selecting cpu frequency, what limitations exist and what design do we want to take to get to a solution. This work is a different take on the patches I posted in November: http://lkml.kernel.org/r/<1413958051-7103-1-git-send-email-mturquette(a)linaro.org> This series depends on having frequency-invariant representations for load. This requires Vincent's recently merged cpu capacity rework patches, as well as a new patch from Morten included here. Morten's patch will likely make an appearance in his energy aware scheduling v4 series. Thanks to Juri Lelli <juri.lelli(a)arm.com> for contributing to the development of the governor. A git branch with these patches can be pulled from here: https://git.linaro.org/people/mike.turquette/linux.git sched-freq Smoke testing has been done on an OMAP4 Pandaboard and an Exynos 5800 Chromebook2. Extensive benchmarking and regression testing has not yet been done. Before sinking too much time into extensive testing I'd like to get feedback on the general design. Michael Turquette (3): sched: sched feature for cpu frequency selection sched: export get_cpu_usage & capacity_orig_of sched: cpufreq_sched_cfs: PELT-based cpu frequency scaling Morten Rasmussen (1): arm: Frequency invariant scheduler load-tracking support arch/arm/include/asm/topology.h | 7 + arch/arm/kernel/smp.c | 53 ++++++- arch/arm/kernel/topology.c | 17 +++ drivers/cpufreq/Kconfig | 24 ++++ include/linux/cpufreq.h | 3 + kernel/sched/Makefile | 1 + kernel/sched/cpufreq_cfs.c | 311 ++++++++++++++++++++++++++++++++++++++++ kernel/sched/fair.c | 48 +++---- kernel/sched/features.h | 6 + kernel/sched/sched.h | 39 +++++ 10 files changed, 475 insertions(+), 34 deletions(-) create mode 100644 kernel/sched/cpufreq_cfs.c -- 1.9.1

11 years, 4 months

EAS on Juno LSK conflicting patches

by Juri Lelli

Hi Alex, Robin asked me to share with you the patches that I found having conflicts on the Juno LSK integration branch. It would be helpful to know your feelings about them (are they fundamental? can they be dropped? etc.). The aim here is to understand if we can eventually come up with a sched-upstream branch that is more easily applicable on top of the Juno integration branch: http://git.linaro.org/landing-teams/working/arm/kernel.git integration-lsk-3.10-juno-android I'll try to give you a list of patches that I had to remove or revert from sched-upstream when trying to build a branch that supports Juno and has EASv3 on top (so that we could test it on Android). I'll also add comments about patches that I'm more familiar with. Please be aware that I had to come up with this in quite a hurry, as we wanted to show EAS results coming from Juno at the last Connect. This means that the rationale for deciding to keep or drop a patch in the branch was merely "drop everything that seems to have non trivial conflicts". At the end I was fairly happy with the behaviours, but this doesn't necessarily mean that we still not need some of what I dropped. 080bdd1 exit.c: unexport __set_special_pids() cdba026 ptrace: revert "Prepare to fix racy accesses on task breakpoints" 73bcb2e mm: remove free_area_cache 802d8c2 ptrace/x86: revert "hw_breakpoints: Fix racy access to ptrace breakpoints" 6472001 ptrace/arm: revert "hw_breakpoints: Fix racy access to ptrace breakpoints" f0a709a sched: Add new scheduler syscalls to support an extended scheduling parameters ABI 631db36 sched/core: Fix htmldocs warnings 4f89001 sched: Preserve the nice level over sched_setscheduler() and sched_setparam() calls c9d415b sched: Fix up scheduler syscall LTP fails 0525ffc sched: Fix up attr::sched_priority warning b62aed3 sched: Move SCHED_RESET_ON_FORK into attr::sched_flags 7d214b1 sched: Fix __sched_setscheduler() nice test 9db9c75 sched: Fix information leak in sys_sched_getattr() 10d4f89 sched: Add 'flags' argument to sched_{set,get}attr() syscalls as this preceding set comes with the (or are subsequent fixes of) the SCHED_DEADLINE patchset, I think we could just ignore them for now 02fee98 ARM: introduce common set_auxcr/get_auxcr functions 6a4f9e7 sched: Implement task_nice() as static inline function this preceding patch is maybe not a crucial fix? 6261e04 sched: Adjust p->sched_reset_on_fork when nothing else changes 33e8006 sched: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE this two preceding patches depend on 6a4f9e7 15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints I then had to revert the following patches. db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu() And finally apply the attached patches to make the branch compile. Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :). Best, - Juri

11 years, 4 months

[RFC 0/6] scheduler-based cpu frequency scaling

by Michael Turquette

This series implements an event-driven cpufreq governor that scales cpu frequency as a function of cfs runqueue utilization. The intent of this RFC is to get some discussion going about how the scheduler can become the policy engine for selecting cpu frequency, what limitations exist and what design do we want to take to get to a solution. This series depends on having frequency-invariant representations for load. This requires Vincent's recently merged cpu capacity rework patches, as well as two patches posted by Morten in his energy aware scheduling v3 series. The latter two patches are included in this series for posterity, but discussion around them probably belongs in the v3 eas series or the forthcoming v4 series. Thanks to Juri Lelli <juri.lelli(a)arm.com> for contributing to the development of the governor. A git branch with these patches can be pulled from here: https://git.linaro.org/people/mike.turquette/linux.git sched-freq Smoke testing has been done on an OMAP4 Pandaboard and an Exynos 5800 Chromebook2. ---8<--- eas-dev, Please let me know what you think of this series, including code as well as cover letter and commitlog text. I was not able to finish the irq_work additions to the governor in time for me to submit this tonight (these changes remove the periodic behavior of calling cap_gov_kick_thread from run_rebalance_domains). I'll focus on the irq_work stuff tomorrow and post an addenedum to this series asap. I have not done any benchmark testing with this series. That is also on my todo list for this week and any help there would be appreciated. Freedom & Howard, if you are bored and feel like measuring power across some benchmarks on your non-buggy EVBs then please do. I can only measure power on the A53s right now which limits me to a single cluster with two cores. Regards, Mike Michael Turquette (4): sched: sched feature for cpu frequency selection cpufreq: add per-governor private data sched: export get_cpu_usage in sched.h sched: cap_gov: PELT-based cpu frequency scaling Morten Rasmussen (2): cpufreq: Architecture specific callback for frequency changes arm: Frequency invariant scheduler load-tracking support arch/arm/include/asm/topology.h | 4 + arch/arm/kernel/topology.c | 41 +++++ drivers/cpufreq/Kconfig | 22 +++ drivers/cpufreq/cpufreq.c | 13 +- include/linux/cpufreq.h | 6 + kernel/sched/Makefile | 1 + kernel/sched/cap_gov.c | 361 ++++++++++++++++++++++++++++++++++++++++ kernel/sched/fair.c | 26 ++- kernel/sched/features.h | 6 + kernel/sched/sched.h | 10 ++ 10 files changed, 488 insertions(+), 2 deletions(-) create mode 100644 kernel/sched/cap_gov.c -- 1.9.1

11 years, 4 months

eas-dev stripping people from cc

by Morten Rasmussen

Hi, It seems that eas-dev is stripping people on cc in certain cases. When I receive copies of my own replies the topic is prefixed with "[Eas-dev]" and the cc list only contains eas-dev itself. Is that a deliberate choice? IMHO it would be better to keep the cc list in case you want to reply to your own messages. It also looks like people are removed from to/cc when others reply to messages received through the list (not in to/cc). Thanks, Morten

11 years, 5 months

sched-freq dependencies

by Mike Turquette

Hi Juri & Morten, Thanks for taking the quick call today. Here are some of the patches from the EAS V3 which I think are outstanding dependencies for sched-freq to be posted on LKML: #4 "sched: Make sched entity usage tracking frequency-invariant" #11 "sched: Make load tracking frequency scale-invariant" #13 "cpufreq: Architecture specific callback for frequency changes" Vincent's fix for setting current freq (should be rolled into #13 above): https://git.linaro.org/people/vincent.guittot/kernel.git/commitdiff/3ac2b6a… #14 "arm: Frequency invariant scheduler load-tracking support" Let me know what you think. Regards, Mike

11 years, 5 months

Re: [Eas-dev] Invitation: sched-dvfs design discussion - Mer. 18 Mars 2015 15:30 - 16:30 (Daniel Lezcano)

by Daniel Lezcano

I have an appointment at this time. Is it possible to delay *2* hours after ? -- Daniel On 03/18/2015 06:29 AM, Mike Turquette wrote: > plus d'infos » > <https://www.google.com/calendar/event?action=VIEW&eid=a2s1amRldW4zY28yMTdlY…> > > > sched-dvfs design discussion > > Link to Google HO is in the meeting details. If that doesn't work for > everyone then we can use some teleconf method. > > The main purpose of the call is to discuss: > 1) locking issues around get_cpu_usage > 2) the polling nature of the current governor code and its implications > 3) designing for the non-blocking DVFS case and for unification of task > placement and frequency selection decisions > > /Date/ > Mer. 18 Mars 2015 15:30 – 16:30 Paris > /Appel vidéo/ > https://plus.google.com/hangouts/_/linaro.org/sched-dvfs > <https://plus.google.com/hangouts/_/linaro.org/sched-dvfs?hceid=bWlrZS50dXJx…> > /Agenda/ > Daniel Lezcano > /Participants/ > > • > Mike Turquette- organisateur > • > Morten Rasmussen > • > Amit Kucheria > • > Daniel Lezcano > • > eas-dev(a)lists.linaro.org > • > Vincent Guittot > • > dietmar.eggemann(a)arm.com > • > Juri Lelli > > Allez-vous participer ? *Oui > <https://www.google.com/calendar/event?action=RESPOND&eid=a2s1amRldW4zY28yMT…>- > Peut-être > <https://www.google.com/calendar/event?action=RESPOND&eid=a2s1amRldW4zY28yMT…>- > Non > <https://www.google.com/calendar/event?action=RESPOND&eid=a2s1amRldW4zY28yMT…>* > plus d'options » > <https://www.google.com/calendar/event?action=VIEW&eid=a2s1amRldW4zY28yMTdlY…> > > Invitation de Google Agenda <https://www.google.com/calendar/> > > Vous recevez ce message à l'adresse daniel.lezcano(a)linaro.org, car vous > êtes abonné aux invitations dans l'agenda Daniel Lezcano. > > Pour ne plus recevoir ces e-mails, veuillez vous connecter à > https://www.google.com/calendar/ et modifier vos paramètres de > notification pour cet agenda. > -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog

11 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

eas-dev