On 31/01/17 13:23, Dietmar Eggemann wrote:
On 26/01/17 00:03, Olav Haugan wrote:
On 17-01-25 13:26:12, Dietmar Eggemann wrote:
On 12/01/17 19:28, Stephen Boyd wrote:
[...]
diff --git a/src/rt-app_parse_config.c b/src/rt-app_parse_config.c index 83794f35fe97..63f69b0c3a15 100644 --- a/src/rt-app_parse_config.c +++ b/src/rt-app_parse_config.c @@ -631,15 +631,44 @@ parse_thread_phase_data(struct json_object *obj, } } +static void parse_cpuset_data(struct json_object *obj, cpu_data_t *data) +{
- struct json_object *cpuset_obj, *cpu;
- /* cpuset */
- cpuset_obj = get_in_object(obj, "cpus", TRUE);
- if (cpuset_obj) {
struct array_list *cpuset;unsigned int i;unsigned int cpu_idx;assure_type_is(cpuset_obj, obj, "cpus", json_type_array);data->cpuset_str = strdup(json_object_to_json_string(cpuset_obj));data->cpusetsize = sizeof(cpu_set_t);data->cpuset = malloc(data->cpusetsize);This allows for situations where the "cpus" field specifies cpus which are not available on the system. A "cpus": [15, 16, 17] on my 16 core systems is not detected as a faulty .json file. We should probe the max core # and compare it within the for loop and bail if we out of range. I guess using a json file on another platform with different topology is a quite common case.
ok, I can do that. The right way of getting max cpus available is sysconf(_SC_NPROCESSORS_CONF), right? I don't want to use _SC_NPROCESSORS_ONLN since some may be hotplugged out at the moment the check is performed.
It depends what we want to allow to happen.
How about we check for hotplug events that might conflict with the specified mask at runtime, instead of at parsing time? And exit with an error or display a warining if we detect such an event (which in general might be just a transient state).
The check against max cpu available is something that we want to do once at parsing time instead, I guess.
Best,
- Juri
If we only consider a default target cpuset (including sparse cpumask due to hotplug) then we could work with a cpu_set_t rtapp_options_t::cpuset which we initialize via sched_getaffinity(0, sizeof(opts.cpuset), &opts.cpuset) before the parsing and then use it later to check the individual cpusets ("cpus": [ x,y,z ],) from the configuration.
Example: ARM JUNO w/ cpu4 hotplug-out
root@juno:~# cat /proc/cpuinfo | grep ^processor processor : 0 processor : 1 processor : 2 processor : 3 processor : 5
So a "cpus": [ 3, 4, 5 ] or [ 6 ] could be detected as an erroneous setup during parsing with this approach:
root@juno:~# /root/devlib-target/bin/rt-app ~/test.json [rt-app] <crit> [json] Invalid cpuset [ 3, 4, 5 ]
root@juno:~# /root/devlib-target/bin/rt-app ~/test.json [rt-app] <crit> [json] Invalid cpuset [ 6 ]
OTAH, "cpus": [ 3,5 ] would be fine:
root@juno:~# /root/devlib-target/bin/rt-app ~/test.json ... [rt-app] <notice> [0] setting cpu affinity to CPU(s) [ 3, 5 ] ...
But this approach would fail if we allow rt-app being started with taskset imposed limitations for the main rt-app task:
root@juno:~# taskset -c 1,2 /root/devlib-target/bin/rt-app ~/test2.json [rt-app] <crit> [json] Invalid cpuset [ 3, 5 ]
We could argue though that the restriction to [ 1, 2 ] is global so [ 3, 5] for a task or task_phase should be detected as configuration error as well.
Opinions?
Cheers,
-- Dietmar
[...] _______________________________________________ Sched-tools mailing list Sched-tools@lists.linaro.org https://lists.linaro.org/mailman/listinfo/sched-tools