On 02/02/17 15:59, Olav Haugan wrote:
On 17-02-01 10:12:54, Juri Lelli wrote:
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.
Yes, lets not get too complicated here. Its not that critical. I can check against ONLN at parsetime.
Maybe I managed to confuse myself, but don't we actually want to use CONF for the static parsing and checking once before start time?
Dealing with hotplug situations is something that we might want to add as e separate patch afterwards, IMHO.
[...]
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?
I would prefer not to have this restriction. Sometimes I really want the rt-app thread itself run on a separate CPU to not conflict with the actual usecase that I am trying to test using the json.
Right, +1.
Thanks,
- Juri