scheduler-tools / rt-app Goto Github PK

View Code? Open in Web Editor NEW

116.0 116.0 98.0 651 KB

rt-app emulates typical mobile and real-time systems use cases and gives runtime information

License: GNU General Public License v2.0

Shell 0.26% C 98.20% Makefile 0.46% M4 1.08%

rt-app's People

Contributors

Stargazers

Watchers

Forkers

gbagnoli credp lookflying vlegout vidblain atschwarz datawolf srikanth007m leo-yan deathsimon javimerino mdigiorgio giraldeau mogarg deggeman jrelo shekkbuilder ted-lin chadizzm bjackman llu87 rbirdic devnebula joelagnel andrecurvello licaiyuren colinianking cloverpop victure86 harshalanka qperret balsini gilsken markivx anwaymukherjee qais-yousef wali-ku jmarinho derkling iamyooon pino-kim vireshk cz172638 kate199696 parthsl sathishscripts intelzhangw2 vflouris radheshyam999 flhofer pirouf rousya rprasathg douglas-raillard-arm peterpuhov-linaro jedichen121 wangyi4 mabinogi80503 psk243 thymbahutymba ankita-020696 vdonnefort joyxu ssg-drd-iot bristot michaelyaoxxx 1343503048 debevv waders909 pierregondois danieljordan10 amamory-ampere wyattgith veysiadn guanbo lovewinner gabrieleara yaozhenguo botieking98 2292384454 honeyflyfish alessiomana kristianmk passionwang davi-btr gatieme jlelli jaankit linuxgiteee cloehle luiskoo luigidematteis epompa10 fx9037curry bjdooks-ct

rt-app's Issues

Create hackbench workload with rt-app

Hi,
I want to create a hackbench workload using rt-app. I tried a few things, but did not get a clear idea about hackbench parameter mapping rt-app options. Also, how can I specify pipe/socket and file descriptors, etc. (used in hackbench) in rt-app. Could anyone please give some suggestions for this?

Thanks

Print in the log file the core used

Hi,
I've tried to modify your code in order to print, in the log file, the core in which threads run at every loop.
In "run" function I inserted this :
ldata->cpu = atoi(tdata->curr_cpu_data->cpuset_str);
and this in "thread_body":
curr_timing->cpu = ldata.cpu;
I also modified data structures, to insert "cpu" field.

I thought the current core information was in the "curr_cpu_data" variable, but printing it I got a different core from the ftrace trace file.

I'd like to ask you if the information about the core in which threads run at every loop are stored somewhere in yout code.

Many thanks for the help.

gnuplot terminal wxt not available

On my system, there is no wxt terminal for gnuplot. There are no instructions on how to enable support for this terminal. I set "eps" instead and it works. Is there any reason why this terminal is used? Thanks.

RTapp fails to run with the right runtime when given a float

In a configuration file like this one, rtapp does not reject "run": 2240.0 but gives a far smaller task than for the integer value of 2240:

{
    "tasks": {
        "invariance_cpu0": {
            "policy": "SCHED_OTHER",
            "delay": 0,
            "loop": 1,
            "phases": {
                "p000001": {
                    "loop": 125,
                    "run": 2240.0,
                    "timer": {
                        "ref": "invariance_cpu0",
                        "period": 16000
                    },
                    "cpus": [
                        0
                    ]
                }
            }
        }
    },
    "global": {
        "default_policy": "SCHED_OTHER",
        "duration": -1,
        "calibration": 312,
        "logdir": "/root/devlib-target"
    }
}

duty cycle issue

Hi,

I define a 50% duty cycle workload and trigger rt-app to execute it. The output log of lowest CPU frequency is as below:

Policy : SCHED_OTHER priority : 0

idx perf run period start end rel_st slack c_run c_period wu_lat

0 1449275 507272 507311 3065362105 3065869416 7960 -108415 200000 400000 0
0 1449275 509090 509127 3065869445 3066378573 515301 -217572 200000 400000 0
0 1449275 506842 506879 3066378600 3066885479 1024456 -324478 200000 400000 0

The problem is c_run is 200 ms (200000 ns) and period is 400 ms as what we defined.
But why actually "run" time is 507272 ns and "period" is 507311 ns?
In my tests, when CPU runs in higher frequency, "run" time and "period" time will be close to 200 ms / 400 ms; but in lower CPU frequency, "run" time and "period" time are larger than 200ms / 400 ms.

Would you like to explain why this happen?

Thanks.

Unable to set affinity for a thread scheduled by shed-deadline

Since affinity setting is currently disabled for tasks handled by sched-deadline, how can we restrict threads to certain cpus but using the policy sched-deadline ?

rtapp execution gives unreliable actual duty cycle

The following JSON configuration was used on a Juno R0, big core running with "performance" cpufreq governor and idle states disabled:

{
    "tasks": {
        "pelt1": {
            "loop": 1,
            "policy": "SCHED_OTHER",
            "phases": {
                "p000001": {
                    "loop": 125,
                    "run": 8000,
                    "timer": {
                        "ref": "pelt1",
                        "period": 16000
                    },
                    "cpus": [
                        1
                    ]
                }
            },
            "delay": 0
        }
    },
    "global": {
        "duration": -1,
        "calibration": 247,
        "default_policy": "SCHED_OTHER",
        "logstats": false,
        "ftrace": "loop",
        "lock_pages": false
    }

This leads to active time in a period of ~8.5ms in one trace and ~9ms in another, instead of 8 in both.
traces.tar.gz

This may be related to the "loop" ftrace configuration, will update the ticket with further information as they come.

This isn't an issue rather a question

Hi Team, i have installed rt-app and my config.json doesn't have any pload in it.

when i rt-app config.json

it gives me different pload, sometimes 16 ns other times 19 ns etc.! why the pload is alterning is it calculating load on server or inserting certain real time delay on server ? is pload 16ns is better than 19ns. Apologies if this seems a silly question, kindly please help me in understanding it better .

what i'm trying to do is to run a container using docker swarm and kubernetes and wanted to see which orchestration is better in load / spinning up a container .! The same stuff again after installing rt-patch

Also, Can you let me know if my understanding is right? period is total time duration that we set for a particular task. due to wu_lat the period that we set (10,000) could vary .! rel_st is the time at which the task actually began due to latency and run is the total time it took to complete the task.!

Here is my config file, FYI (which isn't written by me rather understood up to certain extent by going through tutorial)

Unhandled level 0 translation fault (11)

Running an rt-app with the following configuration

{
    "global": {
        "calibration": 262,
        "default_policy": "SCHED_OTHER",
        "duration": -1,
        "logdir": "/tmp"
    },
    "tasks": {
        "p20_400": {
            "cpus": [
                2
            ],
            "loop": 1,
            "phases": {
                "p000000": {
                    "delay": 350000
                },
                "p000001": {
                    "loop": 12,
                    "run": 80000,
                    "timer": {
                        "period": 400000,
                        "ref": "p20_400"
                    }
                }
            },
            "policy": "SCHED_OTHER"
        },
    }
}

generates a segfault at run-time.

According to the documentation, it seems that delay is not more supported as a phase attribute. However this error is not detected at JSON parsing time thus leading to an wired run-time error.

No output generated

System information: Ubuntu 14.04.4 LTS (GNU/Linux 3.18.31 x86_64)

$ sudo rt-app -t 10000:1000:d -D10
[rt-app] [0] Using SCHED_DEADLINE policy:

Policy : SCHED_DEADLINE

[rt-app] [0] Locking pages in memory

idx period min_et max_et rel_st start end deadline dur. slack Budget Used Budget

[rt-app] [0] starting thread with period: 10000, exec: 1050,deadline: 10000, priority: 0
[rt-app] [0] Exiting.

error with ftrace examples

When running any example with ftrace enable, it causes the following error:

rt-app examples/tutorial/example1.json

Cannot write mark_fd: Bad file descriptor

This error happen when tracing_on is not enabled before writing into trace_marker.

Looking at the following line of code:

  log_notice("configuring ftrace");
  strcpy(tmp, ft_data.debugfs);
  strcat(tmp, "/tracing/tracing_on");
  strcpy(tmp, ft_data.debugfs);
  strcat(tmp, "/tracing/trace_marker");
  ft_data.marker_fd = open(tmp, O_WRONLY);

As can be seen in this code, nothing is written into tracing_on, before writing into trace_marker.
There should be something equivalent to:

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 'something' > /sys/kernel/debug/tracing/trace_marker
echo 0 > /sys/kernel/debug/tracing/tracing_on

Also, it seems that there is no place disabling the tracing.

continue_running confused someone, signal handler behaviour is undefined

i think it [continue_running] doesn't have to be volatile - and there is probably not even a barrier needed, as there are function calls across which there is no optimisation happening inside the loop and when writing continue_running.

without it, my pLoad is about a third of the previous value.

i'll double-check my assumptions and update accordingly.

impossible to reset uclamp

rt-app currently reserves the -1 value as a special "don't modify" value. Unfortunately, -1 is now also a valid value for the clamps for the kernel, with the meaning "remove the clamp".

rt-app should free the -1 internal value (by using -2 or anything else) to let the user pass it to the kernel.

broken examples

"examples/video-short.json" is broken in two ways:

It's not valid JSON
Once the syntax errors are fixed, it's misleading:
Phases like this one:


		"NuPlayerDriver1" : {
			"priority" : -15,
			"loop" : -1,
			"suspend",
			"run" : 100,
			"lock" : "NuPlayerDriver",
			"sync" : { "ref" : "NuPlayerDriver", "mutex" : "NuPlayerDriver" },
			"unlock" : "NuPlayerDriver",
			"run" : 50,
			"suspend" : "NuPlayerDriver",
			"run" : 80,
			"lock" : "NuPlayerDriver",
			"sync" : { "ref" : "NuPlayerDriver", "mutex" : "NuPlayerDriver" },
			"unlock" : "NuPlayerDriver",
			"run" : 370,
			"lock" : "NuPlayerDriver",
			"sync" : { "ref" : "NuPlayerDriver", "mutex" : "NuPlayerDriver" },
			"unlock" : "NuPlayerDriver",
			"run" : 135,
			"resume" : "NuPlayerDriver"
		},

are parsed as containing 6 events: duplicated keys are handled by json-c this way:

the order is insertion order
the value is the value of the last appearance of the key.

This means that the first 2 events will be "suspend" and then "run 135" (135 being the value of the last run). This can be easily observed by running rt-app -l100 video-short.json to get the details of what rt-app is effectively parsing.

This pull request would allow describing such configuration by using an array of events rather than directly have the keys in the phase body: #108

change log level per rt-app invocation

currently, it is a compile-time option which i find a bit tedious. could have a command line flag (how about -l ?). i'm assuming that the overhead is acceptable. could provide a PR, if this feature isn't disliked - ?

Redefined syscall warning

In the master branch, there are multiple warnings about redefined syscall:

ubuntu@tegra-ubuntu:~/rt-app$ make 
Making all in libdl
make[1]: Entering directory `/home/ubuntu/rt-app/libdl'
gcc -DHAVE_CONFIG_H -I. -I../src     -g -O2 -MT dl_syscalls.o -MD -MP -MF .deps/dl_syscalls.Tpo -c -o dl_syscalls.o dl_syscalls.c
In file included from dl_syscalls.c:1:0:
dl_syscalls.h:38:0: warning: "__NR_sched_setattr" redefined [enabled by default]
 #define __NR_sched_setattr  380
 ^
In file included from /usr/include/linux/unistd.h:7:0,
                 from dl_syscalls.h:20,
                 from dl_syscalls.c:1:
/usr/include/arm-linux-gnueabihf/asm/unistd.h:409:0: note: this is the location of the previous definition
 #define __NR_sched_setattr  (__NR_SYSCALL_BASE+380)
 ^

usage: rt-app <taskset.json>

the problem occurs when I try to run rt-app

mlockall always applied by default without graceful failure

The "lock_pages" JSON option is currently documented as applying to rt and deadline classes, but ignored for CFS. The actual behavior is that it's also applied for CFS tasks unless explicitly disabled.

A more reasonable behavior would probably be to enable it by default whenever possible, and when the user specifies something, apply it regardless of the scheduling class or the actual privileges (it's up to the user to come up with a conf file that works, and to rt-app to shout and exit with an error if that's not possible). This would make "lock_pages" available for CFS as well.

Change in uclamp fails if not accompanied by policy

The following JSON currently fails in the sched_setattr() syscall for uclamp:

{
    "tasks" : {
        "task1" : {
            "loop" : 1,
            "phases" : {
                "1" : {
                    "policy": "SCHED_FIFO",
                    "util_min": 256,
                    "run" : 3
                },
                "2" : {
                    "util_min": 512,
                    "run" : 3
                }
            }
        }
    },
    "global" : {
        "default_policy" : "SCHED_OTHER",
        "duration" : 1,
        "gnuplot" : false,
        "logdir" : "./",
        "log_basename" : "testrtapp",
        "lock_pages" : false,
        "frag" : 1,
        "calibration" : 63
    }
}

The reason is that the policy and priority in phase 2 are not set. Therefore, the internal special values THREAD_PRIORITY_UNCHANGED for priority and same for policy will be passed to the sched_setattr() call used for uclamp. Since they are not valid, the kernel rejects them.

Merge GRUB reclaiming

Please, pick commit cc4a31b (from the grub-support branch) in order to have GRUB reclaiming in the master branch. Thanks.

the current version of json-c doesn't define 'TRUE' in json_object.h any longer.

actually since

commit 0992aac61f8b087efd7094e9ac2b84fa9c040fcd
Author: Eric Haszlakiewicz <[email protected]>
Date:   Sat Dec 23 09:42:17 2017 -0500

    Remove the TRUE and FALSE defines.

could provide a PR but don't know which one you'd prefer:

would you rather like in src/rt-app_parse_config.c:

#ifndef TRUE
#include <json_object.h>
#define TRUE ((json_bool)1)
#define FALSE ((json_bool)0)
#endif

#include <stdbool.h>

and rename all TRUEs to true

it is 2018, so we can assume C99 support and we can assume that JSON truth will be the same as the canonical one -?

should it use 0 and 1 as the json-c people seem to intend ("Remove TRUE and FALSE defines, use 1 and 0 instead" 0992aac61f8b087efd7094e9ac2b84fa9c040fcd)

rt-app ignores invalid task names

Invalid task names are ignored by rt-app, instead of aborting. Since that's a user setting, rt-app should either honour it or reject it like for some other settings. The current behaviour creates some issues in automated environments as rt-app keeps going and leads to a trace that does not contain the expected task names. This creates further non obvious errors down the line.

Since the maximum allowed name length is not easily predictable anymore (depending on the suffix size used), it would be best to treat that as an error when non-default is used.

sequence of 'phases' object in rt-app config is undefined - should use an array instead?

according to the JSON standard, the 'phases' object is unordered (http://www.json.org):
"An object is an unordered set of name/value pairs.[...] An array is an ordered collection of values. [...] A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested."

wouldn't it be necessary to use an array here, instead of:

so, instead of:

{
    "global": { ... },
    "tasks": {
        "thread1" : {
            "phases": {
                "phase1": { "run": 10, "sleep": 20 },
            }
        }
    }
}

{
    "global": { ... },
    "tasks": {
        "thread1" : {
            "run": 10,
            "sleep": 20
        }
    }
}

it would be

{
    "global": { ... },
    "tasks": {
        "thread1" : {
            "phases": [
                { "phase1": [ {"run": 10}, {"sleep": 20 }] }
            ]
        }
    }
}

{
    "global": { ... },
    "tasks": {
        "thread1" : [
            { "run": 10}, {"sleep": 20 }
        ]
    }
}

(updated the syntax above, because ironically i got it wrong..)

Asymmetrical treatment of "priority" and "policy"

"priority" and "policy" keys are not treated on the same ground.

Given the base configuration:

{
	  "global": {
		    "duration": -1,
		    "calibration": 265,
		    "lock_pages": false,
		    "logdir": "./"
	  },
	  "tasks": {
		    "invar0": {
		        "loop": 1,
		        "phases": {
			          "phase1": {
			              "policy": "SCHED_FIFO",
			              "priority": 15,
			              "run": 10,
			          },
			          "phase2": {
			              "run": 10,
			          }
		        }
		    }
	  }
}

If "phase2" gets policy=SCHED_FIFO, the priority will be reset to the default value instead of 15 being preserved. If "phase2" gets priority=15, the policy will not get reset and will still be FIFO.

generated gnuplot plot file is wrong

Hi,

The generated plot file is wrong. (Tested with the commit 78ae2cf)
The data file name should be "rt-app1-thread0-0.log" not "rt-app1-thread0--1.log"

sgkim@osboxes:~/work/tmp/rt-app$ sudo ./src/rt-app ./doc/examples/tutorial/example1.json
[rt-app] <notice> [json]         util_min: -1, util_max: -1
[rt-app] <notice> [json]         util_min: -1, util_max: -1
[rt-app] <notice> configuring ftrace
[rt-app] <notice> Calibrate ns per loop
[rt-app] <notice> pLoad = 414ns : calib_cpu 0
[rt-app] <notice> [0] starting thread ...

[rt-app] <notice> [0] Starting with SCHED_OTHER policy with priority 0
[rt-app] <notice> [0] Exiting.
[rt-app] <notice> deconfiguring ftrace
sgkim@osboxes:~/work/tmp/rt-app$ gnuplot rt-app1-run.plot
"rt-app1-run.plot", line 10: warning: Cannot find or open file "rt-app1-thread0--1.log"
"rt-app1-run.plot", line 10: No data in plot
sgkim@osboxes:~/work/tmp/rt-app$ cat rt-app1-run.plot
set terminal postscript enhanced color
set output 'rt-app1-run.eps'
set grid
set key outside right
set title "Measured run time per loop"
set xlabel "Loop start time [usec]"
set ylabel "Run Time [usec]"
set xtics rotate by -45
set key noenhanced
plot "rt-app1-thread0--1.log" u ($5/1000):3 w l title "thread [thread0] (SCHED_OTHER)"
set terminal wxt
replot

uclamp and taskgroup mix issue

Parsing this configuration:

    "tasks" : {
        "task1" : {
            "loop" : 1,
            "phases" : {
                "1" : {
                    "policy": "SCHED_OTHER",
                    "taskgroup": "/",
                    "run" : 3
                },
                "2" : {
                    "util_min": 512,
                    "run" : 3
                }
            }
        }
    },
    "global" : {
        "default_policy" : "SCHED_OTHER",
        "duration" : 1,
        "gnuplot" : false,
        "logdir" : "./",
        "log_basename" : "testrtapp",
        "lock_pages" : false,
        "frag" : 1,
        "calibration" : 63
    }
}

Fails with:

$ sudo rt-app -l100 conf.json     

[rt-app] <info> [json] Reading JSON config from conf.json
[rt-app] <info> [json] Successfully parsed input JSON
[rt-app] <info> [json] root     : { "tasks": { "task1": { "loop": 1, "phases": { "1": { "policy": "SCHED_OTHER", "taskgroup": "\/", "run": 3 }, "2": { "util_min": 512, "run": 3 } } } }, "global": { "default_policy": "SCHED_OTHER", "duration": 1, "gnuplot": false, "logdir": ".\/", "log_basename": "testrtapp", "lock_pages": false, "frag": 1, "calibration": 63 } }
[rt-app] <info> [json] global   : { "default_policy": "SCHED_OTHER", "duration": 1, "gnuplot": false, "logdir": ".\/", "log_basename": "testrtapp", "lock_pages": false, "frag": 1, "calibration": 63 }
[rt-app] <info> [json] tasks    : { "task1": { "loop": 1, "phases": { "1": { "policy": "SCHED_OTHER", "taskgroup": "\/", "run": 3 }, "2": { "util_min": 512, "run": 3 } } } }
[rt-app] <info> [json] Parsing global
[rt-app] <info> [json] Parsing global section
[rt-app] <info> [json]     key: duration, value: 1, type <int>
[rt-app] <info> [json]     key: gnuplot, value: 0, type <bool>
[rt-app] <info> [json]     key: default_policy, value: SCHED_OTHER, type <string>
[rt-app] <debug> ns_per_loop 63
[rt-app] <info> [json]     key: logdir, value: ./, type <string>
[rt-app] <info> [json]     key: log_basename, value: testrtapp, type <string>
[rt-app] <info> [json]     key: ftrace <default> 
[rt-app] <info> [json]     key: lock_pages, value: 0, type <bool>
[rt-app] <info> [json]     key: pi_enabled <default> 0
[rt-app] <info> [json]     key: io_device <default> /dev/null
[rt-app] <info> [json]     key: mem_buffer_size <default> 4194304
[rt-app] <info> [json]     key: cumulative_slack <default> 0
[rt-app] <info> [json] Parsing resources
[rt-app] <info> [json] Parsing resource section
[rt-app] <info> [json] No resource section Found
[rt-app] <info> [json] Parsing tasks
[rt-app] <info> [json] Parsing tasks section
[rt-app] <info> [json]     key: instance <default> 1
[rt-app] <info> [json] Found 1 threads of 1 tasks
[rt-app] <info> [json] Parsing task task1 [-1]
[rt-app] <info> [json]     key: cpus -
[rt-app] <info> [json]     key: policy <default> SCHED_OTHER
[rt-app] <info> [json]     key: priority <default> 0
[rt-app] <info> [json]     key: dl-runtime <default> 0
[rt-app] <info> [json]     key: dl-period <default> 0
[rt-app] <info> [json]     key: dl-deadline <default> 0
[rt-app] <info> [json]     key: util_min <default> -1
[rt-app] <info> [json]     key: util_max <default> -1
[rt-app] <info> [json]     key: runtime <default> 0
[rt-app] <info> [json]     key: period <default> 0
[rt-app] <info> [json]     key: deadline <default> 0
[rt-app] <debug> [json]     key: set scheduler 0 with priority 0
[rt-app] <info> [json]     key: taskgroup <default> 
[rt-app] <info> [json]     key: delay <default> 0
[rt-app] <info> [json]     key: instance <default> 1
[rt-app] <info> [json]     Parsing phases section
[rt-app] <info> [json]     Found 2 phases
[rt-app] <info> [json]     Parsing phase 1
[rt-app] <info> [json] Parsing phase
[rt-app] <info> [json]     key: loop <default> 1
[rt-app] <info> [json]     Found 1 events
[rt-app] <info> [json]     Parsing event run
[rt-app] <info> [json]         type 6 duration 3
[rt-app] <info> [json]     key: cpus -
[rt-app] <info> [json]     key: policy, value: SCHED_OTHER, type <string>
[rt-app] <info> [json]     key: priority <default> 0
[rt-app] <info> [json]     key: dl-runtime <default> 0
[rt-app] <info> [json]     key: dl-period <default> 0
[rt-app] <info> [json]     key: dl-deadline <default> 0
[rt-app] <info> [json]     key: util_min <default> -1
[rt-app] <info> [json]     key: util_max <default> -1
[rt-app] <debug> [json]     key: set scheduler 0 with priority 0
[rt-app] <info> [json]     key: taskgroup, value: /, type <string>
[rt-app] <debug> [tg] # taskgroups allocated [1]
[rt-app] <info> [json]     Parsing phase 2
[rt-app] <info> [json] Parsing phase
[rt-app] <info> [json]     key: loop <default> 1
[rt-app] <info> [json]     Found 1 events
[rt-app] <info> [json]     Parsing event run
[rt-app] <info> [json]         type 6 duration 3
[rt-app] <info> [json]     key: cpus -
[rt-app] <info> [json]     key: policy <default> NULL
[rt-app] <info> [json]     key: priority <default> 2147483647
[rt-app] <info> [json]     key: dl-runtime <default> 0
[rt-app] <info> [json]     key: dl-period <default> 0
[rt-app] <info> [json]     key: dl-deadline <default> 0
[rt-app] <info> [json]     key: util_min, value: 512, type <int>
[rt-app] <info> [json]     key: util_max <default> -1
[rt-app] <debug> [json]     key: set scheduler -1 with priority 2147483647
[rt-app] <info> [json]     key: taskgroup <default> 
[rt-app] <crit> [json]         No taskgroup support for policy (null)
[1]    405210 exit 2     sudo rt-app -l100 conf.json

how to generate ftrace log with sched_switch event

The log below looks very interesting, but I failed to find an example to generate this kind of log.
How to generate ftrace log with sched_switch event? Thanks!

     thread0-23345 [003] 115591.560884: tracing_mark_write: [0] starts
     thread0-23345 [003] 115591.560890: tracing_mark_write: [0] begins loop 0 phase 0 step 0
     thread0-23345 [003] 115591.560894: tracing_mark_write: [0] executing 0
     thread0-23345 [003] 115591.580212: tracing_mark_write: [0] executing 1
     thread0-23345 [003] 115591.580217: sched_switch: prev_comm=thread0 prev_pid=23345 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
      <idle>-0     [003] 115591.670198: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=thread0 next_pid=23345 next_prio=120
     thread0-23345 [003] 115591.670243: tracing_mark_write: [0] end loop 0 phase 0 step 0
     thread0-23345 [003] 115591.670251: tracing_mark_write: [0] begins loop 0 phase 0 step 1
     thread0-23345 [003] 115591.670254: tracing_mark_write: [0] executing 0
     thread0-23345 [003] 115591.688081: tracing_mark_write: [0] executing 1
     thread0-23345 [003] 115591.688085: sched_switch: prev_comm=thread0 prev_pid=23345 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
      <idle>-0     [003] 115591.778063: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=thread0 next_pid=23345 next_prio=120
     thread0-23345 [003] 115591.778108: tracing_mark_write: [0] end loop 0 phase 0 step 1
     thread0-23345 [003] 115591.778116: tracing_mark_write: [0] begins loop 0 phase 0 step 2
     thread0-23345 [003] 115591.778119: tracing_mark_write: [0] executing 0
     thread0-23345 [003] 115591.794619: tracing_mark_write: [0] executing 1
     thread0-23345 [003] 115591.794623: sched_switch: prev_comm=thread0 prev_pid=23345 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
      <idle>-0     [003] 115591.884607: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=thread0 next_pid=23345 next_prio=120
     thread0-23345 [003] 115591.884652: tracing_mark_write: [0] end loop 0 phase 0 step 2

Python 3 compatibility

Please make all the Python scripts compatible with recent versions of Python 3. Python 2 is end of life.

Looks like this question is still valid and unanswered. :-)

Originally posted by @jlelli in #70

Rewritten history?

Hi,

last time I successfully updated rt-app from https://github.com/scheduler-tools/rt-app.git was on 4. November:

git pull --rebase
From git://github.com/scheduler-tools/rt-app
 * [new branch]      wip/merge-linaro-version-1 -> origin/wip/merge-linaro-version-1
Current branch master is up to date.

On 8. November it failed:

From git://github.com/scheduler-tools/rt-app
 + dcaf5a0...fa353e1 master         -> origin/master  (forced update)
 * [new branch]      archive/master -> origin/archive/master
 * [new branch]      wip/merge      -> origin/wip/merge
First, rewinding head to replay your work on top of it...
Applying: .gitignore: Add temp files *~ and .*.swp
Applying: Fix build with --with-json
Using index info to reconstruct a base tree...
M       configure.ac
M       src/Makefile.am
M       src/rt-app_parse_config.h
error: Failed to merge in the changes.
Falling back to patching base and 3-way merge...
Auto-merging src/rt-app_parse_config.h
CONFLICT (content): Merge conflict in src/rt-app_parse_config.h
Auto-merging src/Makefile.am
CONFLICT (content): Merge conflict in src/Makefile.am
Auto-merging configure.ac
CONFLICT (content): Merge conflict in configure.ac
Patch failed at 0002 Fix build with --with-json
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

I haven't changed anything. It would mean, you've rewritten history in this public repository?

Typo in error logging for invalid config

The error logging for exec > period logs the opposite of the actual constraint. I think it should be
Exec must be less than or equal to period .

/* exec time */ exec = get_int_value_from(obj, "exec", FALSE, 0); if (exec > period) { log_critical(PIN2 "Exec must be greather than period"); exit(EXIT_INV_CONFIG); }