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.
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
[...]